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Preface 


The  purpose  of  IDA  Memorandum  Report  M-360,  Level  I  Ada/SQL  Database  Language  Interface,  is  to  forward 
data  developed  in  the  course  of  an  investigation.  This  Memorandum  presents  a  binding  specification  between  the 
programming  language  Ada  and  the  database  language  SQL.  In  particular,  this  specification  is  in  the  exact  format 
which  is  found  in  the  SQL  specification  (i.e.  chapter  names  are  identical) 

The  importance  of  this  document  is  based  on  fulfilling  the  objective  of  Task  Order  T-T5-423,  Defense  Logistics 
Agency  Information  Systems,  which  is  to  provide  a  capability  for  accessing  a  relational  database  from  the  Ada 
language.  M-360  will  be  used  to  provide  a  cross  reference  between  the  Ada/SQL  language  and  the  SQL  language.  As 
a  Memorandum  Report,  M-360  is  directed  to  those  users  of  Ada/SQL  within  the  Defense  Logistics  Agency. 
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This  report  has  been  prepared  in  partial  fulfillment  of  IDA  task  T-T5-423,  "Defense  Logistics  Agency  Information 
Systems."  This  User's  Guide  for  the  Ada/SQL  Database  Language  Interface  addresses  the  functionality  of  the  ANSI 
SQL  standard  but  identifies  a  sub-set  implementation  of  it  as  Level  1.  A  Level  1  implementation  was  delivered  to 
DLA  for  use  with  a  database  package  that  is  intended  for  regional  administrative  systems.  An  Ada  application 
prototype  will  be  implemented  to  demonstrate  software  engineering  using  Ada  in  the  environment  provided  for  these 
regional  administrative  systems. 

IDA  Memorandum  361  is  a  companion  document  that  provides  the  source  listings  for  the  demonstration  software  that 
implements  this  Level  1  version  of  Ada/SQL. 

This  User’s  Guide  specifies  the  syntax  and  semantics  of  Level  1  Ada/SQL.  The  Ada/SQL  DDL  is  used  for  declaring 
the  structures  and  integrity  constraints  of  database  tables  that  will  be  used  with  Ada/SQL  DML  to  manipulate  the 
database  tables  from  within  an  Ada  program. 
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2.  References 


1)  American  National  Standard  "Database  Language  SQL",  ISO/DIS  9075  ANSI  X3.135-1986,  dated  May 
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2)  Military  Standard  Ada  Programming  Language.  ANSI/MIL-STD-18I5A,  dated  January  1983 
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3.  Overview 


3.1.  Organization 

1)  Clause  3.2  "Notation''  defines  the  syntactic  notation  used  in  the  manual. 

2)  Clause  3.3  "Conventions"  define  the  terms  used  to  specify  the  syntactic  elements  in  this  manual. 

3)  Clause  4  "Concepts"  defines  terms  and  presents  concepts  used  in  the  definition  of  Ada/SQL,  explains 
why  limitations  were  placed  on  certain  Ada  concepts  and  discusses  possible  future  enhancements. 

4)  Clause  5  "Common  Elements”  defines  language  elements  that  occur  in  several  parts  of  Ada/SQL. 

5)  Clause  6  "Schema  Definition  Language"  defines  in  detail  the  design  of  the  DDL  used  for  specifying 
database  tables. 

6)  Clause  7  "Program  Environment"  defines  the  program  environment  required  for  an  Ada/SQL  program. 

7)  Clause  8  "Data  Manipulation  Language"  defines  the  statements  uses  in  Ada/SQL  to  manipulate  data 
within  the  databases. 


3.2.  Notation 

The  syntactic  notation  used  in  this  document  is  a  blend  of  the  simple  variants  of  BNF  ("Backus  Normal  Form"  or 
"Backus-Naur  Form")  used  in  the  ANSI  Standard  SQL  Document  and  the  Ada  Programming  Language  Military 
Standard.  The  extensions  noted  below  augment  BNF.  The  syntax  is  as  follows: 

Square  brackets  ([])  indicate  optional  elements. 

Ellipses  (...)  indicate  elements  that  may  be  repeated  one  or  more  times. 

Braces  (( 1)  group  sequences  of  elements. 

Boldface  words  are  used  to  denote  reserved  words. 

A  vertical  bar  separates  alternative  items  unless  it  occurs  immediately  after  an  opening  brace,  in  which  case  it  stands 
for  itself. 

If  the  name  of  any  syntactic  category  starts  with  an  underlined  prefix,  it  is  equivalent  to  the  category  name  without  the 
prefix.  The  prefix  is  intended  to  convey  some  semantic  information. 

In  the  BNF  syntax,  a  production  symbol  <A>  is  defined  to  "contain"  a  production  symbol  <B>  if  <B>  occurs 
someplace  in  the  expansion  of  <A>.  If  <A>  contains  <B>,  then  <B>  is  "contained  in"  <A>  If  <A>  contains  <B>, 
then  <A>  is  the  "containing"  <A>  production  symbol  for  <B>. 

3.3.  Conventions 

Syntactic  elements  of  this  manual  are  specified  in  terms  of: 

1)  Function:  A  short  statement  of  the  purpose  of  the  element 

2)  Format:  A  BNF  definition  of  the  syntax  of  the  element 

3)  Syntax  Rules:  Additional  syntactic  constraints  not  expressed  in  BNF  that  the  element  shall  satisfy. 

4)  Level  l  Implementation  Rules:  Syntactic  constraints  specific  to  Level  1  Ada! SQL  that  the  element  shall 
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S)  General  Rules:  A  sequential  specification  of  the  run-time  effect  of  the  element. 

In  the  Syntax  Rules,  the  term  "shall"  defines  conditions  that  are  required  to  be  true  of  syntactically  conforming 
Ada/SQL  language. 

In  the  Level  1  Implementation  Rules,  the  term  "shall"  defines  conditions  that  are  required  to  be  true  in  AdaJSQL  Level 
I ,  but  are  expected  to  change  in  future  levels. 

In  the  General  Rules,  the  term  "shall"  defines  conditions  that  are  tested  at  run-time  during  the  execution  of  Ada/SQL 
statements.  If  all  such  conditions  are  true,  then  the  statement  executes  successfully.  If  any  such  condition  is  false, 
then  the  statement  does  not  execute  successfully  and  the  statement  execution  has  no  effect  on  the  database,  the 
SQLCODE  parameter  is  set  and  an  exception  may  be  raised.  Note:  Level  1  Ada/SQL  will  not  set  SQLCODE,  but  will 
raise  exceptions. 

The  elements  described  in  this  manual  for  Ada/SQL  are  standard  Ada  elements.  Not  all  features  of  an  Ada  element 
may  be  permitted  in  conjunction  with  Ada/SQL  statements.  Limitation  of  an  element  in  Ada/SQL  only  limits  its  use 
when  used  in  direct  association  with  the  Ada/SQL  portions  of  a  compilation  unit. 
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4.  Concepts 


4.1.  Sets 

A  set  is  an  unordered  collection  of  distinct  objects. 

A  multi-set  is  an  unordered  collection  of  objects  that  are  not  necessarily  distinct. 

A  sequence  is  an  ordered  collection  of  objects  that  are  not  necessarily  distinct. 

The  cardinality  of  a  collection  is  the  number  of  objects  in  that  collection.  Unless  specified  otherwise,  any  collection 
may  be  empty. 


4.2.  Data  Types 

A  data  type  is  a  set  of  representable  values.  The  logical  representation  of  a  value  is  a  <literal>.  The  physical 
representation  of  a  value  is  implementor-defined.  The  implementor-defined  representation  of  values  will  have  no 
affect  on  programs  and/or  the  use  of  the  Ada/SQL  system,  providing  programs  use  only  those  logical  operations  on 
data  that  are  representation-independent  Hence,  Ada/SQL  programs  may  be  fully  transportable. 

A  value  is  primitive,  in  that  it  has  no  logical  subdivision  within  this  specificatioa  A  value  is  a  null  value  or  a  nonnull 
value. 

A  null  value  is  an  implementor-defined  type-dependent  special  value  that  is  distinct  from  all  nonnull  values  of  that 
type. 

A  non-null  value  may  be  of  any  data  type  defined  for  Ada/SQL:  character  string  (one  dimensional  array  of 
characters),  integer,  floating  point  number,  and  enumeration,  the  value  of  any  program  object,  of  a  permit!  -d  type, 
may  be  stored  within  a  database  column. 


4.2.1.  Character  Strings 

A  character  string  consists  of  a  sequence  of  characters  of  the  predefined  type  CHARACTER  defined  in  the  Ada 
STANDARD  package.  A  character  string  has  a  length,  which  is  a  positive  integer  that  specifies  the  number  of 
characters  in  the  sequence. 

Character  strings  may  be  defined  as  STRINGS  or  as  any  single-dimension  array  of  CHARACTER  with  integer  index. 
Character  strings  are  the  only  Ada/SQL  data  types  defined  as  Ada  arrays. 

Character  strings  are  comparable  in  <Ada/SQL  statements  only  if  they  are  of  the  same  Ada  type.  A  character  string 
is  identical  to  another  character  string  if  and  only  if  it  is  equal  to  that  character  string  in  accordance  with  the 
comparison  rules  specified  in  5.1 1,  "<comparison  predicate>’\ 

A  character  string  value  shall  only  be  assigned  to  a  data  item  or  program  variable  of  the  same  type. 


4.2.2.  Numbers 

A  number  is  either  an  exact  numeric  value  (Ada  integer  types)  or  an  approximate  numeric  value  (Ada  floating  point 
types).  Ada  fixed  point  types  are  not  supported  in  Level  1 . 

An  exact  numeric  value  is  a  whole  number,  either  positive,  negative  or  zero.  An  exact  numeric  value  can  be 
constrained  to  fall  within  a  range. 
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An  approximate  numeric  value  consists  of  a  mantissa  and  an  exponent.  The  mantissa  is  a  signed  numeric  value,  and 
the  exponent  is  a  signed  integer  that  specifies  the  magnitude  of  the  mantissa.  An  approximate  numeric  value  has  a 
precision.  The  precision  is  a  positive  integer  that  specifies  the  number  of  significant  decimal  digits  in  the  mantissa. 
An  approximate  numeric  value  can  be  constrained  to  fall  within  a  range. 

Numbers  are  comparable  in  <Ada/SQL  statements  only  if  they  are  of  the  same  Ada  type.  A  number  is  identical  to 
another  number  if  and  only  if  it  is  equal  to  that  number  in  accordance  with  the  comparison  rules  specified  in  5.1 1, 
"comparison  predicate^'. 

A  number  value  shall  only  be  assigned  to  a  data  item  or  program  variable  of  the  same  type. 


4.2.3.  Enumeration  Types 

Enumeration  types  as  defined  by  Ada  syntax  are  permitted.  Enumeration  types  are  characterized  by  a  sequence  of 
values  which  define  ordered  sets  in  which  possible  values  are  explicitly  listed.  The  predefined  enumeration  types 
CHARACTER  and  BOOLEAN  will  be  recognized.  CHARACTER  is  an  enumeration  type  with  values  of  the  128 
characters  of  the  ASCII  code.  BOOLEAN  is  an  enumeration  type  with  values  of  TRUE  and  FALSE.  The  Ada/SQL 
operations  available  on  enumeration  types  are  the  same  as  are  available  on  strings,  except  that  LIKE  is  not  available 
for  enumeration  types.  The  representation  clause  for  enumeration  types  is  not  permitted  in  Level  1 . 

Enumeration  types  will  be  represented  in  the  database  such  that  their  Ada  sort  order  is  preserved. 

Enumeration  values  are  comparable  in  <Ada/SQL  statements  only  if  they  are  of  the  same  Ada  type.  An  enumeration 
value  is  identical  to  another  enumeration  value  if  and  only  if  it  is  equal  to  that  enumeration  value  in  accordance  with 
the  comparison  rules  specified  in  5.1 1,  "comparison  predicate^'. 

An  enumeration  value  shall  only  be  assigned  to  a  data  item  or  program  variable  of  the  same  type. 


4.3.  Columns 

A  column  is  a  multi-set  of  values  that  may  vary  over  time.  All  values  of  the  same  column  are  of  the  same  data  type 
and  are  values  in  the  same  table.  A  value  of  a  column  is  the  smallest  unit  of  data  that  can  be  selected  from  a  table  and 
the  smallest  unit  of  data  that  can  be  updated. 

A  column  has  a  description  and  an  ordinal  position  within  a  table.  The  description  of  a  column  includes  its  data  type 
(which  includes  range  constraints)  and  indication  of  whether  the  column  is  constrained  to  contain  only  nonnull  or 
nonnull/unique  values.  The  description  of  a  character  string  column  includes  its  length.  The  description  of  a  floating 
point  numeric  column  includes  the  number  of  digits  of  precision  and  upper  and  lower  numeric  bounds.  The 
description  of  an  integer  numeric  column  includes  upper  and  lower  numeric  bounds.  The  description  of  an 
enumeration  column  includes  the  enumeration  literals  and  their  order. 

A  named  column  is  a  column  of  a  named  table  or  a  column  that  inherits  the  description  of  a  named  column.  The 
description  of  a  named  column  includes  its  name. 


4.4.  Tables 

A  table  is  a  multi-set  of  rows.  A  row  is  a  nonempty  sequence  of  values.  Every  row  of  the  same  table  has  the  same 
cardinality  and  contains  a  value  of  every  column  of  that  table.  The  n*  value  in  every  row  of  a  table  is  a  value  of  the 
0th  column  of  that  table.  The  row  is  the  smallest  unit  of  data  that  can  be  inserted  into  a  table  and  deleted  from  a  table. 

The  degree  of  a  table  is  the  number  of  columns  of  that  table.  At  any  time,  the  degree  of  a  table  is  the  same  as  the 
cardinality  of  each  of  its  rows  and  the  cardinality  of  a  table  is  the  same  as  the  cardinality  of  each  of  its  columns. 

A  table  has  a  description.  The  description  includes  a  description  of  each  of  its  columns. 


8 


DRAFT 


A  base  table  is  a  named  table  defined  by  a  <table  definitions  The  description  of  a  base  table  includes  its  name. 


A  derived  table  is  a  table  derived  directly  or  indirectly  from  one  or  more  other  tables  by  the  evaluation  of  a  <query 
specifications  The  values  of  a  derived  table  are  those  of  the  underlying  tables  when  it  is  derived. 

A  viewed  table  is  a  named  derived  table.  In  Level  1  AdaISQL,  a  viewed  table  is  defined  with  a  <table  definition>,  just 
as  is  a  base  table.  The  actual  view  definition  must  also  be  defined  to  the  underlying  database  using  the  DBMS  DDL. 
The  description  of  a  viewed  table  includes  its  name.  Future  levels  of  Add  SQL  will  include  the  capability  to  specify 
<vie w  definition>s. 

A  table  is  either  updatable  or  read-only.  The  operations  of  insert,  update,  and  delete  are  permitted  for  updatable  tables 
and  are  not  permitted  for  read  only  tables. 

A  grouped  table  is  a  set  of  groups  derived  during  the  evaluation  of  a  <group  by  clauses  A  group  is  a  multi-set  of 
rows  in  which  all  values  of  the  grouping  column(s)  are  equal.  A  grouped  table  may  be  considered  as  a  collection  of 
tables.  Set  functions  may  operate  on  the  individual  tables  within  the  grouped  table. 

A  grouped  view  is  a  viewed  table  derived  from  a  grouped  table. 


4.5.  Integrity  Constraints 

Integrity  constraints  define  the  valid  states  of  the  database  by  constraining  the  values  in  the  base  tables.  Constraints 
may  be  defined  to  prevent  two  rows  in  a  table  from  having  the  same  values  in  a  specified  column  or  columns 
(_NOT_NULL_UNIQUE)  or  to  prevent  a  column  from  containing  a  null  value  (_NOT_NULL).  For  Level  1 
AdaISQL  multiple  column  unique  constraints  must  be  defined  in  the  underlying  DBMS  DDL  only.  There  is  no  way  to 
define  multiple  column  uniqueness  in  Level  1  AdaISQL. 

The  integrity  constraints  _NOT_NULL  and  _N0T_NULL_UN1QUE  are  effectively  checked  after  execution  of  each 
<Ada/SQL  statements  If  the  base  table  associated  with  a  _NOT_NULL  or  _NOT_NULL_UNIQUE  integrity 
constraint  does  not  satisfy  that  integrity  constraint,  then  the  <Ada/SQL  statement*  has  no  effect,  and  the  appropriate 
error  indication  is  returned. 

The  integrity  constraints  _NOT_NULL  and  _NOT_NULL_UNIQUE  must  be  placed  on  columns  of  a  base  table 
(through  the  DDL  of  the  underlying  DBMS)  for  the  constraint  to  be  adhered  to.  These  constraints  shall  also  be  placed 
on  the  appropriate  columns  when  tables  are  defined  in  the  Ada/SQL  DDL.  However  only  the  constraints  placed 
through  the  underlying  DBMS  will  be  checked  after  the  execution  of  statements. 

Numeric  and  enumeration  values  which  may  be  contained  in  a  column  may  be  given  range  constraints,  indicating  the 
low  value  and  high  value  permitted  in  that  column  in  the  database. 

Range  constraints  are  placed  on  columns  of  database  tables  through  table  definitions  in  the  Ada/SQL  DDL.  The 
underlying  DBMS  may  or  may  not  allow  such  constraints  to  be  placed  on  columns  via  its  DDL. 

When  using  a  program  value,  to  directly  set  the  value  of  a  column  in  a  database  table,  range  constraints  are  effectively 
checked  after  execution  of  each  <Ada/SQL  statemeno.  If  the  program  value  does  not  satisfy  the  range  constraint  the 
<Ada/SQL  statement*  has  no  effect  on  the  table.  Range  constraints  will  not  be  checked  in  Level  l  AdaISQL. 

Range  constraints  will  not  be  checked  if  the  value  set  in  the  constrained  column  is  not  stricdy  a  program  value,  i.e.  if 
it  is  generated  within  the  database,  unless  the  underlying  DBMS  has  the  ability  to  restrict  columns  in  such  a  way. 

Range  constraints  will  be  checked  for  all  columns  when  they  are  retrieved  from  the  database.  If  the  retrieved  value 
does  not  satisfy  the  column’s  range  constraint  an  exception  will  be  noted.  Range  constraints  will  not  be  checked  in 
Level  1  AdaISQL. 
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4.6.  Schemas 


A  <scbema>  is  a  persistent  object  specified  by  the  Ada/SQL  schema  definition  language  (Ada/SQL  DDL).  It  consists 
of  all  <table  definitions  known  to  the  system  for  a  specified  authorization  identifier*  in  an  environment.  The 
"environment"  for  an  Ada/SQL  system  includes  all  <schema>s  that  may  be  accessed  through  it. 

The  tables  defined  by  a  <schema>  are  considered  to  be  "owned  by"  the  authorization  identifier*  specified  for  that 
<schema>.  In  Level  1  Ada/SQL,  tables  and  views  must  be  created,  dropped  or  altered  and  privileges  defined  outside 
of  the  Ada/SQL  environment  using  the  DDL  appropriate  for  the  underlying  DBMS;  several  parts  of  the  required  DDL 
are  not  defined  for  Level  1  Ada/SQL  and  no  automated  tool  is  supplied  to  translate  Ada/SQL  DDL  to  the  DDL  of  the 
underlying  DBMS. 


4.7.  The  Database 

The  database  is  the  collection  of  all  data  defined  by  the  <schema>s  in  an  environment. 


4.8.  Program  Environment 

An  Ada/SQL  program  environment  is  an  Ada  application  program,  possibly  consisting  of  multiple  subprograms,  using 
Ada/SQL  DDL  to  define  one  or  more  databases  and  Ada/SQL  DML  to  manipulate  data  in  the  defined  databases.  An 
Ada/SQL  program  environment  consists  of  zero  or  more  cursors  specified  by  <declare  cursoi>s,  and  one  or  more  calls 
to  Ada/SQL  DML  statements.  The  program  environment  for  an  Ada/SQL  system  includes  all  <schema>s  that  may  be 
accessed  through  it 


4.9.  Procedures 

Procedures,  as  defined  by  SQL,  are  not  used  in  Ada/SQL. 


4.10.  Parameters 

Parameters,  as  defined  by  SQL,  are  not  used  in  Ada/SQL. 


4.10.1.  SQLCODE 

The  SQLCODE  is  a  special  program  variable  of  type  integer.  Its  value  is  set  to  a  status  code  that  either  indicates  that 
a  call  to  the  DML  completed  successfully  or  that  an  exception  condition  occurred  during  execution  of  the  DML 
statement.  Note:  Level  l  Ada/SQL  will  not  set  SQLCODE  but  will  raise  exceptions. 

4.10.1.1.  Exceptions 

Status  in  Ada/SQL  is  returned  by  raising  the  appropriate  exception  on  error.  The  following  exceptions  are  defined 
and  discussed  throughout  this  manual:  UNIQUE_ERROR,  NULL.ERROR,  NOT_FOUND_ERROR. 


4.10.2.  Indicator  Variables 

An  indicator  variable  is  a  program  variable,  constant  or  literal  of  type  INDICATOR. VARIABLE,  which  is  an 
enumeration  type  with  values  of  NULL.VALUE  and  NOT.NULL,  that  is  specified  after  another  parameter  in  a  call 
to  a  DML  procedure.  Its  primary  use  is  to  indicate  whether  the  value  that  the  preceding  parameter  assumes  or 
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supplies  is  a  null  value. 


4.11.  Standard  Programming  Languages 

Ada  is  the  only  programming  language  that  the  Ada/SQL  system  is  designed  to  work  with. 


4.12.  Cursors 

A  cursor  is  specified  by  a  <declare  cursor>. 

For  each  <declare  cursoo  in  a  program  environment,  a  cursor  is  effectively  created  by  the  execution  of  a  <declare 
cursor>  and  destroyed  when  the  program  defining  it  terminates. 

A  cursor  is  in  either  the  open  state  or  the  closed  state.  The  initial  state  of  a  cursor  is  the  closed  state.  A  cursor  is 
placed  in  the  open  state  by  an  copen  statement  and  returned  to  the  closed  state  by  a  cclose  statements  a  ccommit 
statements  or  a  crollback  statements 

A  cursor  in  the  open  state  designates  a  table,  an  ordering  of  the  rows  of  that  table,  and  a  position  relative  to  that 
ordering.  If  the  cdeclare  cursor>  does  not  specify  an  corder  by  clauses  then  the  rows  of  the  table  have  an  order 
defined  by  the  underlying  DBMS.  This  order  is  subject  to  the  reproducibility  requirement  within  a  transaction,  but  it 
may  change  between  transactions.  Any  program  relying  on  an  order  defined  by  the  underlying  DBMS  is  erroneous. 

The  position  of  a  cursor  in  the  open  state  is  either  before  a  certain  row,  on  a  certain  row,  or  after  the  last  row.  If  a 
cursor  is  on  a  row,  then  that  row  is  the  current  row  of  the  cursor.  A  cursor  may  be  before  the  first  row  or  after  the  last 
row  even  though  the  table  is  empty. 

A  cfetch  statement*  advances  the  position  of  an  open  cursor  to  the  next  row  of  the  cursors  ordering  and  retrieves  the 
values  of  the  columns  of  that  row.  An  cupdate  statement:  positioned>  updates  the  current  row  of  the  cursor.  A 
cdelete  statement:  positioned>  deletes  the  current  row  of  the  cursor. 

If  a  cursor  is  before  a  row  and  a  new  row  is  inserted  at  that  position,  then  the  effect,  if  any  on  the  position  of  the  cursor 
is  defined  by  the  underlying  DBMS.  Any  program  relying  on  that  position  is  erroneous. 

If  a  cursor  is  on  a  row  or  before  a  row  and  that  row  is  deleted,  than  the  cursor  is  positioned  before  the  row  that  is 
immediately  after  the  position  of  the  deleted  row.  If  such  a  row  does  not  exist,  then  the  position  of  the  cursor  is  after 
the  last  row. 

If  an  error  occurs  during  the  execution  of  an  <Ada/SQL  statement>  that  identifies  an  open  cursor,  then  the  effect,  if 
any,  on  the  position  or  state  of  that  cursor  is  defined  by  the  underlying  DBMS.  Any  program  relying  on  the  position 
or  state  of  that  cursor  is  erroneous. 
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The  table  designated  by  an  open  cursor  is  either  a  temporary  base  table  or  a  temporary  viewed  table.  The 
determination  of  whether  a  given  cursor  designates  a  temporary  base  table  or  a  temporary  viewed  table  is  defined  by 
the  underlying  DBMS.  Any  program  relying  on  this  is  erroneous. 

Each  row  of  a  temporary  viewed  table  is  derived  only  when  the  cursor  is  positioned  on  that  row. 

A  temporary  base  table  is  created  when  the  cursor  is  opened  and  destroyed  when  the  cursor  is  closed. 

4.13.  Statements 

An  <Ada  SQL  statement  specifies  a  database  operation  or  a  cursor  operation.  A  <select  statement  fetches  values 
from  a  table.  An  <insert  statement*  inserts  rows  into  a  table.  A  -cupdate  statement:  searcbed>  or  cupdate  statement: 


DRAFT 


11 


positioned  updates  the  values  in  rows  of  a  table.  A  <delete  statement:  searched  or  <delete  statement:  positioned 
deletes  rows  of  a  table. 


4.14.  Embedded  Syntax 

An  <embedded  Ada/SQL  host  program>  uses  exact  Ada  syntax  that  may  be  compiled  by  any  standard,  validated  Ada 
compiler.  The  embedded  SQL  syntax  conforms  to  Ada  syntax. 


4.15.  Privileges 

A  privilege  authorizes  certain  actions  (insert,  delete,  select,  and  update)  to  be  performed  on  a  specified  table  by  a 
specified  <authorization  identifier*.  Privileges  are  not  defined  by  the  Level  l  Ada/SQL  DDL.  The  creation  of  tables 
and  the  setting  of  privileges  is  done  outside  of  the  Ada/SQL  environment  by  the  DBA  using  the  DDL  as  required  by 
the  underlying  DBMS. 

An  <authorization  identifier*  is  specified  for  each  <schema>. 

The  authorization  identifier*  specified  for  a  <schema>  shall  be  different  from  the  authorization  identifier*  of  any 
other  <schema>  in  the  same  environment.  The  < authorization  identifier*  of  a  <schema>  is  the  "owner"  of  all  tables 
and  views  defined  in  that  <schema>. 

Tables  and  views  are  designated  by  <table  name>s.  A  <table  name>  consists  of  an  authorization  identifier*  and  an 
<identifier>.  The  <authorization  identifier*  identifies  the  <schema>  in  which  the  table  or  view  designated  by  the 
<table  name>  was  defined.  Tables  and  views  defined  in  different  <schema>s  can  have  the  same  identifier*.  A 
<schema>  has  a  single  authorization  identifier*.  It  may,  however,  be  defined  within  one  or  more  <schema  package 
declarations.  Each  schema  package  declaration  is  an  Ada  package. 

If  a  reference  to  a  <table  name>  does  not  explicitly  contain  an  authorization  identifier*,  then  the  appropriate 
authorization  identifier*  of  the  containing  <schema>  is  specified  by  default  providing  that  reference  was  made 
within  a  <schema>.  If  the  reference  was  not  made  within  a  <schema>,  the  applicable  <schema  package  declaration* 
and  corresponding  < authorization  identifier  are  selected  according  to  Ada  visibility  rules  for  table  names  without  an 
explicitly  stated  authorization  identifier  or  package  name  prefix. 

The  <authorization  identifier*  of  a  <schema>  has  all  privileges  on  the  tables  and  views  defined  in  that  <schema>. 

A  <schema>  with  a  given  authorization  identifier*  may  contain  <privilege  definitions  that  grant  privileges  to  other 
authorization  identifiers.  The  granted  privileges  may  apply  to  tables  and  views  defined  in  the  current  <schema>,  or 
they  may  be  privileges  that  were  granted  to  the  given  authorization  identifier*  by  other  <schemas.  The  WITH 
GRANT  OPTION  clause  of  a  <privilege  definition>  specifies  whether  the  recipient  of  a  privilege  may  grant  it  to 
others.  <privilege  definition>s  are  not  implemented  in  Level  1  of  Ada/SQL.  All  <privilege  definition>s  must  be  set 
through  the  underlying  DBMS. 


4.16.  Transactions 

A  transaction  is  a  sequence  of  operations,  including  database  operations,  that  is  atomic  with  respect  to  recovery  and 
concurrency.  Transactions  terminate  with  a  ccommit  statement*  or  a  <rollback  statement*.  If  a  transaction 
terminates  with  a  ccommit  statement*,  then  all  changes  made  to  the  database  by  that  transaction  are  made  accessible 
to  all  concurrent  transactions.  If  a  transaction  terminates  with  a  crollback  statement*,  then  all  changes  made  to  the 
database  by  that  transaction  are  canceled.  Committed  changes  cannot  be  canceled.  Changes  made  to  the  database  by 
a  transaction  can  be  perceived  by  that  transaction,  but  cannot  be  perceived  by  other  transactions  until  that  transaction 
terminates  with  a  ccommit  state ment>. 

The  execution  of  concurrent  transactions  is  guaranteed  to  be  serializable.  A  serializable  execution  is  defined  to  be  an 


execution  of  tbe  operations  of  concurrently  executing  transactions  that  produces  the  same  effect  as  some  serial 
execution  of  those  same  transactions.  A  serial  execution  is  one  in  which  each  transaction  executes  to  completion 
before  the  next  transaction  begins. 

The  execution  of  an  <Ada/SQL  statement  within  a  transaction  has  no  effect  on  the  database  other  than  the  effect 
stated  in  the  General  Rules  for  that  <Ada/SQL  statements  Together  with  serializable  execution,  this  implies  that  all 
read  operations  are  reproducible  within  a  transaction,  except  for  changes  explicitly  made  by  the  transaction  itself. 

Valid  execution  of  any  Ada/SQL  data  manipulation  statement  other  than  <declare  cursor*  initiates  a  transaction  for 
the  executing  program,  if  one  is  not  already  in  progress.  A  transaction  in  progress  upon  program  termination  is 
automatically  terminated  as  if  a  <rollback  statement*  had  been  issued. 


4.17.  Philosophy 

The  limitations  and  constraints  placed  on  the  Ada  statements  described  in  this  manual  reflect  the  limitations  of  Level  1 
Ada/SQL.  For  Level  1  of  Ada/SQL  we  have  elected  to  keep  the  DDL  as  similar  to  SQL’s  as  possible  without  losing 
the  advantage  of  Ada’s  strong  typing  and  enumeration  types.  With  this  simplification  of  Ada/SQL  to  SQL  format,  we 
have  lost  some  of  the  advanced  features  of  Ada.  These  features  will  be  implemented  in  a  later  Level  of  Ada/SQL. 
These  restrictions  of  Level  1  affect  only  the  part  of  an  Ada  program  immediately  concerned  with  Ada/SQL,  the  DDL 
and  <Ada/SQL  statements. 

Level  1  Ada/SQL  will  not  contain  a  DDL  generator  to  generate  DDL  for  the  underlying  Database  Management 
System  (DBMS)).  The  DBMS  DDL  must  be  created  separately  by  the  DBA.  The  DBMS  DDL  will  contain  table 
creation,  setting  unique  columns,  view  creation,  and  privileges.  Level  1  Ada/SQL  DDL  will  be  used  only  to  describe 
table  formats  and  column  data  types  to  the  Ada/SQL  system.  A  table  must  be  defined  to  the  database  before  the 
Ada/SQL  System  can  access  it  The  classification  package  of  the  schema,  as  defined  by  the  proposed  Ada/SQL 
MIL-STD  (but  not  required  by  the  ANSI  standard)  which  defines  the  security  classification  of  all  columns  in  each 
table  defined  in  the  schema  packages,  will  not  be  implemented  in  Level  1.  All  security  will  be  through  privileges 
defined  by  the  DBMS  DDL. 

Level  1  Ada/SQL  DDL  will  be  used  only  to  describe  table  formats,  column  data  types,  range  restrictions,  and  not  null 
and  unique  limitations.  Therefore  the  DDL  package  ADA.SQL  will  contain  only  type  definitions.  It  may  contain  no 
function  specifications,  call  no  subprograms  and  declare  no  objects.  Neither  the  ADA_SQL  package  nor  its  enclosing 
package  is  to  have  a  body,  since  view  definitions,  privilege  definitions  and  multiple  column  uniqueness  constraints  are 
not  processed  in  Level  1  Ada/SQL  DDL;  these  constructs  will  be  placed  in  package  bodies  in  later  levels  of  Ada/SQL. 

As  mentioned  earlier  for  Level  1  Ada/SQL  we  have  elected  to  keep  the  DDL  and  DML  as  similar  to  SQL's  as 
possible  without  losing  the  advantage  of  Ada’s  strong  typing  and  enumeration  types.  Therefore  we  have  eliminated 
some  of  the  more  advanced  features  of  the  type  definitions  for  this  level. 

Following  is  a  list  of  Ada  features  not  allowed  in  the  Level  1  Ada/SQL  DDL. 

1)  Nested  packages  are  not  permitted  except  for  the  special  case  of  the  nested  package  ADA_SQL  required 
in  all  DDL  units. 

2)  Private  sections  are  not  permitted. 

3)  Package  bodies  are  not  permitted. 

4)  Ada  attributes  are  not  permitted. 

5)  Renaming  declarations,  generic  declarations,  generic  instantiations,  deferred  constant  declarations, 
subprogram  declarations,  task  declarations,  exception  declarations,  object  declarations,  and  number 
declarations  are  not  permitted. 

6)  Variables,  constants  and  named  numbers  are  not  permitted. 

7)  All  ranges,  index  constraints  etc.  are  to  be  defined  with  literals,  not  with  variables,  constants  or  complex 
expressions. 
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8)  All  expressions  are  to  be  simple  literals,  no  math  may  be  performed,  oo  functions  such  as  ABS  or  NOT 
may  be  referenced,  no  relational  operators  such  as  =  >  <  may  be  used  and  no  variables  or  constants  may 
be  used. 

9)  Based  literals  are  not  permitted,  all  numeric  literals  must  be  decimal. 

10)  No  default  values  may  be  assigned  to  any  types. 

1 1)  Access  types,  private  types,  task  types,  incomplete  type  declarations  and  representation  clauses  may  not 
be  used. 

12)  Array  types  must  be  made  up  of  CHARACTER  components  and  be  of  one  dimension  only  with  integer 
index 

13)  Records  may  not  contain  discriminants,  variant  parts  or  unconstrained  arrays;  records  must  be  defined  as 
being  of  fixed  length.  Record  components  may  not  be  of  record  types. 

14)  Fixed  point  numbers  may  not  be  used.  Floating  point  and  integer  may  be  used. 

15)  Type  conversions  may  not  be  used. 


4.18.  Level  l  vs  Future  Levels 


FUTURE  LEVELS  OF  Ada/SQL 


This  illustration  shows  the  interaction  of  the  different  parts  of  Ada/SQL  in  Level  1.  The  DBMS  DDL  is  used  to  define 
Si  create  the  framework  of  the  database.  The  Ada/SQL  DDL  mirrore  parts  of  the  DBMS  DDL, .such*  ^ 
tables  The  definitions  in  the  Ada/SQL  DDL  are  used  by  the  Ada/SQL  programs  to  operate  on  the  database.  The 
features  eliminated  in  Level  1  of  Ada/SQL  DDL  are  those  not  required  by  the  Ada/SQL  programs  to  operate  on  the 

database. 
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5.  Common  Elements 
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5.1.  <character> 

Function 

Define  the  terminal  symbols  of  the  language  and  the  elements  of  strings. 

Format 

< character* 

<digit>  I  defter*  I  <special  character*  I  <space  character 
<digit>  ::= 

0123456789 

<lettei>  ::= 

<upper  case  letter*  I  <lower  case  letter* 

-cupper  case  letter*  ::= 

ABCDEFGHIJKLMNOPQRSTUVWXYZ 
•dower  case  letter*  ::= 

abcdefghijklmnopqrstuvwxyz 
-especial  character* 

[  \  ]  A  ‘  {  }  ~ 

-cspace  character*  ::= 
space 

cformat  effector*  ::= 

horizontal  tabulation,  vertical  tabulation,  carriage  return, 
line  feed,  form  feed 

Syntax  Rules 

1)  The  only  characters  allowed  in  Ada/SQL  are  the  <character*s  defined  here,  including  the  format 
effectors. 

General  Rules 

None. 


ft 
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5.2.  <literal> 


Function 

Specify  a  nonnull  value. 

Format 

<literal>  ::= 

enumeration  Uteral> 

I  <character  string  literal> 

I  <numeric  literal> 

<r enumeration  literal>  ::= 

<identifier> 

I  <cbaracter  literal> 

^character  literal> 

’<character*’ 

character  string  literal> 

"<character  representation..." 

<cbaracter  representation  ::= 

<nonquote  character* 

I  <quote  representation 

<nonquote  character* 

See  Syntax  Rule  4. 

<quote  representation 

tin 

cnumenc  literals  ::= 

<decimal  literal> 

<decimal  literal>  ::= 

<integer>  [.<integer>]  [<exponent>] 

cinteger* 

<digit>  [( [<underscore>]  <digit>}...] 

<underscore> 

<exponent>  ::= 

E  [+]  <tnteger> 

I  E  -  <integer> 

Syntax  Rules 

1)  An  enumeration  literal>  yields  a  value  that  belongs  to  an  enumeration  type. 

2)  A  character  literal>  is  formed  by  enclosing  one  of  the  95  <character>s  (including  the  <space 
character*)  between  two  apostrophe  <character>s  (’).  A  <character  literal>  has  a  value  that  belongs  to  a 
character  type.  The  predefined  type  CHARACTER  is  an  enumeration  type  with  the  values  of  the  128 
characters  of  the  ASCII  code. 

3)  A  <cfaaracter  string  literab*  is  formed  by  a  sequence  of  <character>s  (possibly  none)  enclosed  between 
two  quotation  characters  used  as  string  brackets. 
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4)  A  <nooquote  character*  is  any  <character>  other  than  the  double  quote  mark  character  ("). 

5)  A  <character  string  literal>  yields  a  value  that  belongs  to  a  character  string  type  (a  one-dimensional 
array  of  CHARACTER  with  integer  index).  The  length  of  a  <character  string  literal>  is  the  number  of 
<character  representations  that  it  contains.  Each  <quote  represents tion>  in  a  ccharacter  string  literal> 
represents  a  single  quotation  mark  character  in  both  the  value  and  the  length  of  the  <character  string 
literals 

6)  There  are  two  classes  of  <numeric  literals:  real  literals  and  integer  literals.  A  real  literal  is  a  <numeric 
literal>  that  includes  a  point  (.);  an  integer  literal  is  a  <numeric  literals  without  a  point.  Real  literals  are 
the  literals  of  the  type  univeisal_real.  Integer  literals  are  the  literals  of  the  type  uni versal_inte ger.  An 
exponent  for  an  integer  literal  must  not  have  a  minus  sign.  Numeric  literals  may  be  automatically 
converted  to  any  other  similar  (integer  vs.  real)  numeric  type. 

7)  An  <underscore>  character  inserted  between  adjacent  <digits  of  a  <decimal  literals  does  not  affect  the 
value  of  this  <numeric  literals  The  letter  E  of  the  exponent,  if  any,  can  be  written  either  in  lower  case 
or  in  upper  case,  with  the  same  meaning. 

8)  A  <numeric  literal>  may  be  a  <based  literals  in  Ada.  In  Level  1  Ada/SQL  <based  literals  are  not 
permitted.  All  numeric  literals  are  assumed  to  be  decimal. 

General  Rules 

1)  The  evaluation  of  a  <literal>  yields  the  corresponding  value. 

2)  enumeration  literalss  include  ccharacter  literalss  and  yield  values  of  the  corresponding  enumeration 
types. 

3)  A  ccharacter  string  literal>  is  a  basic  operation  that  combines  the  sequence  of  characters  it  contains  into 
a  value  of  a  character  string  type;  the  lower  bound  of  this  array  is  given  by  S 'FIRST  where  S  is  the 
index  subtype;  the  upper  bound  is  determined  by  the  length. 

4)  For  a  ccharacter  string  literal*  containing  no  ccharacter  representations,  the  upper  bound  is  the 
predecessor,  as  given  by  the  PRED  attribute,  of  the  lower  bound.  The  evaluation  of  a  such  a  ccharacter 
string  literal*  returns  an  error  if  the  lower  bound  does  not  have  a  predecessor. 

5)  For  the  evaluation  of  a  ccharacter  string  literal*  containing  one  or  more  ccharacter  representations,  a 
check  is  made  that  the  index  range  defined  belongs  to  the  index  subtype.  The  exception 
CONSTRAINT_ERROR  is  raised  if  any  of  these  checks  fails. 

6)  The  type  of  a  ccharacter  string  literal*  must  be  determinable  solely  from  the  context  in  which  this  literal 
appears,  excluding  the  literal  itself,  but  using  the  fact  that  a  ccharacter  string  literal>  is  a  value  of  a  one 
dimensional  array  type  whose  component  type  is  a  character  type. 

7)  The  character  literals  corresponding  to  the  ccharacter  representations>  used  within  a  ccharacter  string 
literal:*  must  be  visible  at  the  place  of  the  ccharacter  string  literal:*  (although  these  characters 
themselves  are  not  used  to  determine  the  type  of  the  ccharacter  string  literal>). 

8)  The  numeric  value  of  a  cdecimal  literal*  is  derived  from  the  normal  mathematical  interpretation  of 
positional  decimal  notation  (that  is,  the  base  is  implicitly  ten).  An  cexponenc*  indicates  the  power  of 
ten  by  which  the  value  of  the  cdecimal  literal>  without  the  exponent  is  to  be  multiplied  to  obtain  the 
value  of  the  cdecimal  literal*  with  the  cexponent*. 
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5.3.  <token> 


Functioa 


Specify  lexical  units. 


Format 


<token> 

<noode limiter  token>  I  <delimiter  token> 


<nonde  limiter  token>  ::= 
<ddentifien> 

I  <SQL  key  word> 

I  <Ada  key  word> 

I  <Ada/SQL  key  wond> 
I  <literal> 


<SQL  key  word>  ::= 

ALL  I  AND  I  ANY  I  AS  I  ASC I  AUTHORIZATION  1  AVG I  BEGIN  I  BETWEEN 
I  BY  I  CHAR  I  CHARACTER  I  CHECK  I  CLOSE  I  COBOL  I  COMMIT  I  CONTINUE 
I  COUNT  I  CREATE  I  CURRENT  I  CURSOR  I  DEC  I  DECIMAL  I  DECLARE  I  DELETE 
I  DESC I  DISTINCT  I  DOUBLE  I  END  I  ESCAPE  I  EXEC  I  EXISTS  I  FETCH 
I  FLOAT  I  FOR  I  FORTRAN  I  FOUND  I  FROM  I  GO  I  GOTO  I  GRANT  I  GROUP 
I  HAVING  I  IN  I  INDICATOR  I  INSERT  I INT I  INTEGER  I  INTO  I  IS 
I  LANGUAGE  I  LIKE  I  MIX  I  MIN  I  MODULE  I  NOT  I  NULL  I  NUMERIC  I  OF 
I  ON  I  OPEN  I  OPTION  I  OR  I  ORDER  I  PASCAL  I  PU  1  PRECISION  I  PRIVILEGES 
I  PROCEDURE  I  PUBLIC  I  REAL  I  ROLLBACK  I  SCHEMA  I  SECTION  I  SELECT  I  SET 
I  SMALLINT I  SOME  I  SQL  I SQLCODE I  SQLERROR  I  SUM  I  TABLE  1  TO  I  UNION 
I  UNIQUE  I  UPDATE  I  USER  I  VALUES  I  VIEW  I  WHENEVER  I  WHERE  I  WITH  I  WORK 


<Ada  key  word>  ::= 

ABORT  I  ABS  I  ACCEPT  I  ACCESS  I  ALL  I  AND  I  ARRAY  I  AT  I  BEGIN  1  BODY 
I  CASE  I  CONSTANT  I  DECLARE  I  DELAY  I  DELTA  I  DIGITS  I  DO  I  ELSE  I  ELSIF 
I  END  I  ENTRY  I  EXCEPTION  I  EXIT  I  FOR  I  FUNCTION  I  GENERIC  I  GOTO  I  IF 
I  IN  I  IS  I  LIMITED  I  LOOP  I  MOD  I  NEW  I  NOT  I  NULL  1  OF  I  OR  I  OTHERS 
I  OUT  I  PACKAGE  I  PRAGMA  I  PRIVATE  I  PROCEDURE  I  RAISE  1  RANGE  I  RECORD 
I  REM  I  RENAMES  I  RETURN  I  REVERSE  I  SELECT  I  SEPARATE  I  SUBTYPE  I  TASK 
I  TERMINATE  I  THEN  I  TYPE  I  USE  I  WHEN  I  WHILE  I  WITH  1  XOR 


<Ada/SQL  key  word>  ::= 

ACS  1 ALLL I  AND  I  ANY  I  AVG  I  AVG.ALL  I  AVG.DISTINCT  I  BETWEEN 
I  CLOSE  I  COMMIT.WORK  I  COUNT  I  COUNT.DISTINCT  I  CURSOR_FOR  I  DECLAR 
I  DELETE JFROM I  DESC  I EQ I  ESCAPE  I  EXISTS  1  FETCH  I  FROM  I  GROUP.BY 
I  HAVING  I  INDICATOR  I  INSERT  INTO  I  INTO  I  IS_IN  l  IS_NOT_NULL  I  IS_NULL 
I  LIKE  I  MAX  I  MAX.ALL  I  MAX.DISTINCT  I  MIN  I  MIN_ALL  I  MIN.DISTINCT 
I  NE I  NOT  I  NOTJN  I  NULL  VALUE  I  OPEN  I  OR  I  ORDER.BY  I  ROLLBACK_WORK 
I  SELEC I  SELECT_ALL  I  SELECT_DISTINCT  I  SET  I  SOME  I  SUM  I  SUM_ALL 
I  SUM_DISTTNCT  I  UNION  I  UNION. ALL  I  UPDATE  I  USER  I  VALUES  I  WHERE 
I  WHERE  CURRENT  OF 


<delimiter  token>  ::= 

&l  ’1(1  )l  *1  +  1 ,1-1.  I/I  :l;  I  <  I  =  I  >  I  (1}  l=> 

|  ..  |  **  |  ;=  |  /=  |  >=  |  <=  |  «  |  »  |  O 


<separator> 

<space  character* 
I  <format  effector* 
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I  end  of  a  line 


<comment>  ::= 

~[<characten>...]<newline> 

<newline>  ::= 

implementor  defined  end  of  line  indicator 

Syntax  Rules 

1)  A  <token>,  other  than  a  character  string  literal>  or  a  character  literals  shall  not  include  a  <space 
character. 

2)  Any  <token>  may  be  followed  by  a  <separaton>.  A  <nonde limiter  token>  shall  be  followed  by  a 
<de limiter  token>  or  a  <separator>.  If  the  syntax  does  not  allow  a  <nondelimiter  token>  to  be  followed 
by  a  <de limiter  token>,  then  that  <nondelimiter  token>  shall  be  followed  by  a  <separator>. 

General  Rules 

None. 
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Format 

<name>  ::= 

cample  aame> 

I  character  literal> 


<simple  name>  ::= 
<identifier> 

<coIumn  name>  ::= 
cdentifier 


<table  name>  ::= 

<selected  component  table  name> 

I  <underscorcd  table  name> 

I  <hyphenated  table  name> 

<package  name>  ::= 

<unit  simple  name> 

I  <unit  simple  name>  [ .  <unit  simple  name>  ] ... 

<unit  simple  name>  ::= 

<identifier> 

<selected  component  table  name>  ::= 

[  <authorization  identifier  .  ]  cable  identifier 

<underscored  table  name>  ::= 

[  <authorization  identifier  _  ]  cable  identifier 

hyphenated  table  name>  ::= 

[  <authorization  identifier  -  ]  cable  identifier 

<authorization  identifier  ::= 
cdentifier 

cable  identifier  ::= 
cdentifier 


cype  identifier  ::= 
cdentifier 

<conelatioo  name  declaration  ::= 
package  correlation  name>  is 

new  cable  name>_CORRELATION.NAME  [  ("cdentifier")  ] ; 

correlation  name> 
cdentifier 

<subtype  identifier  ::= 

cdentifier  [  _NOT_NULL  [  .UNIQUE  ]  ] 
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1)  A  <table  oame>  identifies  a  named  table.  In  most  contexts  where  an  <authorization  identifier  is  used 
within  a  cable  name>,  the  <authorization  identifier  is  separated  from  the  <table  identifier  by  a 
period.  There  are,  however,  isolated  occurrences  where  the  separator  character  is  an  underscore,  (see 
the  "<from  clause>"),  or  a  hyphen  (see  the  "<view  definition^'  and  the  "cinsert  statemenr".  <view 
definition>  will  be  defined  in  a  later  Ada! SQL  Level. 

2)  If  a  <table  name>  does  not  contain  an  <authorization  identifier,  then: 

a)  If  a  <table  name>  is  contained  in  a  <schema>,  then  the  authorization  identifier  specified  as  the 
<scfaema  authorization  identifier  of  the  <schema>  is  implicit 

b)  If  the  <table  name>  is  contained  outside  a  <schema>,  then  the  <authorization  identifier  as 
chosen  by  the  Ada  visibility  rules  is  implicit 

3)  Two  <table  name>s  are  equal  if  and  only  if  they  have  the  same  <table  identifier  and  the  same 
authorization  identifier,  regardless  of  whether  the  <  authorization  identifiers  are  implicit  or  explicit 

4)  A  <table  name>  is  declared  by  the  <table  definition>  directly  containing  it. 

3)  A  <table  name>  in  an  <Ada/SQL  statemenr  shall  identify  a  table  defined  in  one  of  the  <schema>s  of 
the  containing  programs. 

6)  Case: 

a)  If  a  <table  name>  is  directly  contained  in  a  <correlation  name  declaration>,  then  it  shall  be 
written  as  an  <underscored  table  name>. 

b)  If  a  <table  name>  is  directly  contained  in  a  <view  definition>  containing  a  <view  column  list>  or 
an  -arise  it  statemenr  containing  an  <insert  column  lisr,  then  it  shall  be  written  as  a 
<hyphenated  table  name>.  <view  definition>  will  be  defined  in  a  later  Ada/SQL  Level. 

c)  Otherwise,  a  <table  name>  shall  be  written  as  a  <selected  component  table  name>. 

7)  A  <package  name>  identifies  a  named  Ada  package,  which  may  be  qualified  to  identify  a  nested 
package. 

8)  A  <unit  simple  name>  identifier  an  unqualified  named  Ada  package. 

9)  An  <authorization  identifier  represents  an  authorization  identifier. 

10)  The  <identifier  of  a  <type  identifier  shall  have  been  defined  previously  with  a  type  or  subtype 
declaration. 

11)  An  identifier  is  declared  as  a  correlation  name>  for  a  particular  table  by  a  correlation  name 
declaration>  directly  containing  that  correlation  name>  and  the  <table  name>  that  identifies  the  table. 
The  same  correlation  name>  may  be  reused  within  different  scopes  of  the  same  statement,  although  it 
must  refer  to  different  instances  of  the  same  table. 

12)  If  the  ccorrelation  name  declararion>  contains  the  optional  identifier,  then  that  identifier  shall 
match  the  correlation  name>  declared. 

13)  The  use  of  a  correlation  name>  in  a  cfrom  clause>  associates  a  scope  with  that  use  of  the  correlation 
name>.  The  scope  is  either  a  <select  statemenr,  <subquery>,  or  <query  specification>.  Scopes  may  be 
nested.  The  same  correlation  name>  may  be  associated  with  several  different  scopes,  but  may  not  be 
associated  with  the  same  scope  more  than  once. 

14)  The  correlation  name  declaratiorr  for  a  correlation  name>  used  in  a  <£rom  clause>  shall  be  directly 
visible,  by  Ada  visibility  rules,  at  the  point  in  the  source  text  at  which  the  <from  clause>  appears. 

13)  A  < column  name>  identifies  a  named  column.  An  cidentifier  is  defined  as  a  <column>  by  a  cable 
definitions 

16)  Names,  other  than  authorization  identifiers,  table  identifiers  and  column  names  defined  in  the  DDL,  may 
be  any  valid  Ada  identifiers,  except  that  they  may  not  be  the  same  as  <SQL  key  words>,  <Ada  key 
words>  or  <Ada/SQL  key  words>.  Names  of  authorization  identifiers,  table  identifiers  and  column 
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names  are  limited  to  18  characters. 

17)  <subtype  identifiers  may  include  the  suffixes  _NOT_NULL  or  _NOT_NULL_UNIQUE.  Database 
columns  defined  by  record  components  of  subtypes  named  with  these  suffixes  shall  have  the 
corresponding  SQL  constraints. 

Level  l  Implementation  Rules 

1)  authorization  identifiers>  are  not  used  by  UNIFY.  UNIFY  limits  <table  identifiers  to  8  characters 
and  <column  name>s  to  16  characters. 

General  Rules 

None. 
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5.4.1.  <identifier> 

Function 

Identifiers  are  used  as  names  and  reserved  words. 

Format 

<identifier>  ::= 

<letter>  [{[<undeiscore>]  <letter  ordigio}...] 

<underscore>  ::=  _ 

<letter  or  digit>  ::= 

<letter> 

I  <digit> 

Syntax  Rules 

1)  Identifiers  perform  their  usual  Ada  functions  within  schemas,  but  are  also  used  to  name  SQL 
authorization  identifiers,  tables,  and  columns. 

2)  An  <ddentifier>  may  consist  of  as  many  characters  as  permitted  by  Ada,  except  <identifier>s  relating 
directly  to  the  database,  such  as  authorization  identifiers,  table  names,  column  names,  etc,  which  may 
consist  of  no  more  than  18  <character>s. 

3)  A  user-defined  <idenhfier>  shall  not  be  identical  to  an  <SQL  key  word>,  an  <Ada  key  word>,  or  an 
<Ada/SQL  key  word>  as  defined  in  Clause  5.3  "<token>". 

4)  Identifiers  used  as  subtype  names  may  include  the  suffixes  _NOT_NULL  or  _NOT_NULL_UNIQUE. 
Database  columns  defined  by  record  components  of  subtypes  named  with  these  suffixes  shall  have  the 
corresponding  SQL  constraints. 

5)  Case  is  not  significant  in  an  <identifier>. 

General  Rules 

None. 
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5.5.  <data  typo 


Function 

Specify  a  data  type. 

Format 

<datatype>  ::= 

<string  type  definition 
I  -dnteger  type  definition 
I  <real  type  definition 
I  enumeration  type  definition 

Syntax  Rules 

1)  A  database  column  of  a  subtype  having  a  null  range  must  not  be  declared  as  _NOT_NULL  or 
_NOT_NULL_UNIQUE  —  only  mill  values  may  be  stored  within  it.  (The  usefulness  of  such  a  column 
would  be  extremely  limited.) 

2)  Ada/SQL  supports  die  predefined  type  CHARACTER  which  is  an  enumeration  type  with  the  values  of 
the  128  characters  of  the  ASCII  code. 

3)  Ada/SQL  supports  the  predefined  type  BOOLEAN  which  is  an  enumeration  type  with  the  values  of 
FALSE  and  TRUE. 

4)  Ada/SQL  supports  the  predefined  integer  type  of  INTEGER,  as  well  at  the  NATURAL  (zero  and  greater 
than  zero)  and  POSITIVE  (greater  than  zero)  subtypes.  Other  implementor  optional  predefined  types 
defined  in  the  STANDARD  package,  such  as  SHORT_INTEGER  and  LONGJNTEGER,  are  also 
supported,  as  appropriate  for  each  implementation. 

5)  Ada/SQL  supports  the  predefined  teal  type  FLOAT.  Other  implementor  optional  predefined  types 
defined  in  the  STANDARD  package,  such  as  SHORT_FLOAT  and  LONG_FLOAT,  are  also  supported, 
as  appropriate  for  each  implementation. 

6)  Ada/SQL  supports  the  predefined  type  STRING.  The  values  of  the  predefined  type  STRING  are 
one -dimensional  arrays  of  the  predefined  type  CHARACTER,  indexed  by  values  of  the  predefined 
subtype  POSITIVE. 

7)  There  may  be  other  predefined  types  in  the  package  STANDARD  and/or  other  system  dependent 
packages.  All  of  these  predefined  types  may  be  used  in  Ada/SQL,  provided  they  are  within  a  class 
described  above. 

General  Rules 

None. 
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5.5.1.  <string  type  definition? 

Function 

Define  a  string  data  type. 

Format 

<string  type  definition?  ::= 

cunconstrained  array  definition? 

I  <cons trained  array  definition? 

cunconstrained  array  definition?  ::= 
array  (<index  subtype  definition?) 
of  ccomponent  subtype  indication? 

<constrained  array  definitioa?  ::= 

array  cindex  constraint?  of  ccomponent  subtype  indication? 

cindex  subtype  definition?  ::= 

<type  mark?  range  <? 

Syntax  Rules 

1) For  cstring  type  definition?  all  arrays  shall  have  a  single  integer  index  with  components  of 
CHARACTER  type. 

2)  For  <cons trained  array  definition?,  arrays  shall  have  a  single  integer  index  with  components  of 
CHARACTER  type;  the  cindex  constraint?  shall  have  positive  bounds;  and  the  ccomponent  subtype 
indication?  shall  be  of  CHARACTER  type  and  have  no  associated  cconstraint?. 

3)  For  cunconstrained  array  definition?,  the  ctype  mark?  of  the  cindex  subtype  definition?  shall  be  of  an 
integer  type.  The  ccomponent  subtype  indication?  shall  be  of  CHARACTER  type  and  have  no 
associated  cconstraint?. 

General  Rules 

None. 
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5.5.2.  cinteger  type  definition 

Function 

Define  an  integer  data  type. 

Format 

<integer  type  definition> :  := 

•orange  constraint 

Syntax  Rules 

1)  Each  bound  of  the  <range>  of  the  <range  constraint  shall  be  of  an  integer  type. 

General  Rules 

1)  Integer  values  are  positive  or  negative  integers  or  zero.  Integer  types  may  have  range  constraints  which 
identify  a  lower  and  upper  limit  of  valid  numbers  associated  with  the  type.  The  range  of  integers 
supported  by  a  database  management  system  may  not  be  the  same  as  that  supported  by  the  Ada  system 
used  to  access  that  DBMS.  The  package  DATABASE  provides  information  about  the  DBMS  being 
accessed  by  Ada/SQL.  In  particular,  the  smallest  (most  negative)  integer  value  supported  by  the  DBMS 
through  Ada/SQL  is  the  named  number  DATABASE.MtN_ENT  and  the  largest  (most  positive)  value  is 
DATABASE.MAXJNT.  The  type  DATABASE.INTG  is  defined  to  encompass  the  maximum  range  of 
integers  supported  by  the  DBMS  through  Ada/SQL. 

2)  The  DATABASE  package  also  includes  the  definition  of  a  type  SMALLINT,  with  range  corresponding 
to  that  supported  by  the  DBMS  type  SMALLINT  through  Ada/SQL.  Ada/SQL  will  convert  Ada  integer 
data  types  to  the  corresponding  DBMS  types  as  follows:  (1)  If  the  Ada  type  or  subtype  declaration 
explicitly  references  (following  a  chain  of  references)  INTEGER  or  DATABASE.INTG,  then  the  SQL 
INTEGER  type  is  used,  (2)  if  the  declaration  of  the  Ada  type  or  subtype  explicitly  references 
SMALLINT,  then  the  SQL  SMALLINT  type  is  used,  (3)  if  none  of  these  types  is  referenced  in  the  Ada 
declarations,  then  the  SQL  SMALLINT  type  is  used  if  the  range  of  values  is  compatible  with  it, 
otherwise  the  SQL  INTEGER  type  is  used. 

3)  If  the  range  of  integers  supported  by  the  DBMS  is  smaller  than  that  supported  by  Ada.  then  Ada/SQL 
will  issue  warning  diagnostics  upon  encountering  explicitly  declared  ranges  that  extend  beyond  the 
capability  of  the  DBMS.  The  execution  of  an  Ada/SQL  operation  that  would  require  the  DBMS  to 
handle  an  integer  beyond  its  range  will  cause  an  error  indication  to  be  returned  to  the  program,  unless 
the  erroneous  operation  is  performed  entirely  within  the  DBMS  and  is  not  detected  by  the  DBMS. 

4)  SQL  does  not  support  subtypes,  so  database  operations  may  be  performed  without  range  checking.  (An 
implementation  may  perform  range  checking  where  practical,  however,  returning  an  error  on  database 
operations  that  would  violate  subtype  constraints.)  If  range  checking  is  not  performed,  it  is  possible  for 
an  Ada/SQL  statement  to  cause  one  or  more  database  columns  to  contain  values  outside  the  ranges 
defined  for  those  columns.  An  error  will  be  returned,  however,  when  it  is  attempted  to  retrieve  such 
values.  If  the  value  can  be  legally  stored  in  the  variable  used  to  retrieve  it,  then  the  value  will  be  stored 
before  the  error  is  returned. 
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5 .5.3.  creal  type  definition 

Function 

Define  a  real  data  type. 

Format 

creal  type  definitioa>  ::= 

cfloating  point  constraint> 

Syntax  Rules 

None. 

General  Rules 

1)  Real  types  represent  approximations  of  numbers,  with  precision  to  a  specified  number  of  significant 
digits,  and  an  optional  restriction  on  their  range.  The  range  and  accuracy  of  real  numbers  supported  by  a 
database  management  system  may  not  be  the  same  as  that  supported  by  the  Ada  system  used  to  access 
that  DBMS.  If  the  range  or  accuracy  of  real  numbers  supported  by  the  DBMS  is  smaller  than  that 
supported  by  Ada,  then  Ada/SQL  will  issue  warning  diagnostics  upon  encountering  explicitly  declared 
characteristics  that  extend  beyond  the  capability  of  the  DBMS.  An  error  is  returned  by  the  execution  of 
an  Ada/SQL  operation  that  would  require  the  DBMS  to  handle  a  real  number  beyond  its  range,  unless 
the  erroneous  operation  is  performed  entirely  within  the  DBMS  and  is  not  detected  by  the  DBMS.  In 
general,  no  error  is  returned  if  accuracy  is  lost  as  a  result  of  database  operations. 

2)  The  underlying  DBMS  must  support  the  model  numbers  (according  to  the  Ada  definition)  for  types  that 
are  successfully  processed  by  Ada/SQL  as  well  as  safe  numbers  within  the  ranges  of  subtypes.  The 
DBMS  may  also  support  a  wider  range  of  safe  numbers. 

3)  The  comments  on  range  checking  and  errors  for  integers  are  applicable  to  real  numbers  as  well. 

4)  The  DATABASE  package  defines  REAL  and  DOUBLE_PRECISION  types,  with  ranges  and  accuracies 
corresponding  to  those  supported  by  the  SQL  REAL  and  DOUBLE  PRECISION  types  as  available  from 
the  underlying  DBMS  through  Ada/SQL.  Ada/SQL  will  convert  Ada  floating  point  types  to  the 
corresponding  DBMS  types  as  follows:  (1)  If  the  Ada  type  or  subtype  declaration  explicitly  references 
(following  a  chain  of  references)  DOUBLE_PRECISION,  then  the  SQL  DOUBLE  PRECISION  type  is 
used,  (2)  if  the  declaration  of  the  Ada  type  or  subtype  explicitly  references  REAL,  then  the  SQL  REAL 
type  is  used,  (3)  if  neither  DOUBLE_PRECISION  nor  REAL  is  referenced  in  the  Ada  declarations,  then 
a  SQL  FLOAT  type  with  appropriate  precision  is  used  if  the  range  and  accuracy  of  values  is  compatible 
with  it,  otherwise  the  SQL  DOUBLE_PRECISION  type  is  used.  Note  that  the  range  and  accuracy  of  the 
Ada  FLOAT  type  may  not  correspond  to  those  achievable  with  the  SQL  FLOAT  type. 

5)  The  maximum  number  of  floating  point  digits  that  can  be  handled  by  Ada/SQL  through  the  underlying 
DBMS  is  given  by  the  system  dependent  named  number  DATABASE.MAX_DIGITS. 
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5 .5.4.  enumeration  type  definition> 

Function 

Defines  an  enumeration  data  type. 

Format 

<enumeration  type  definition>  ::= 

(<e numeration  literal  spedfication> 
j,  enumeration  literal  spedfication>  } ... ) 

<enumeration  literal  spedfication>  ::= 
enumeration  literal> 

Syntax  Rules 

1)  An  < enumeration  literal>  shall  be  an  <identifier>  or  <character  literal>. 

2)  The  <identifier>s  and  <character  literals  listed  by  an  <enumeration  type  definition>  must  be  distinct. 

3)  Each  enumeration  literal>  of  an  enumeration  type  has  a  position  number  which  is  an  integer  value. 
Each  enumeration  literal>  yields  a  different  enumeration  value.  The  predefined  order  relations 
between  enumeration  values  follow  the  order  of  corresponding  position  numbers.  The  position  number 
of  the  value  of  the  first  listed  enumeration  literal>  is  zero;  the  position  number  for  each  other 
enumeration  literal>  is  one  more  than  for  its  predecessor  in  the  list 

General  Rules 

None. 
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5.5.5.  <derived  type  definition> 


Function 

Define  a  derived  data  type. 

Format 

<deiived  type  definition  ::= 

new  <subtype  indication 

Syntax  Rules 

1)  A  derived  type  definition  defines  a  new  (base)  type  whose  characteristics  are  derived  from  those  of  a 
parent  type:  the  new  type  is  called  a  derived  type.  A  derived  type  definition  further  defines  a  derived 
subtype,  which  is  a  subtype  of  the  derived  type. 

2)  The  <subtype  indication  defines  the  parent  subtype.  The  parent  type  is  the  base  type  of  the  parent 
subtype.  If  a  constraint  exists  for  the  parent  subtype,  a  similar  constraint  exists  for  the  derived  subtype; 
the  only  difference  is  that  for  a  range  constraint  and  likewise  for  a  floating  constraint  that  includes  a 
range  constraint,  the  value  of  each  bound  is  replaced  by  the  corresponding  value  of  the  derived  type. 

3)  The  derived  type  belongs  to  the  same  class  of  types  as  the  parent  type.  The  set  of  possible  values  for  the 
derived  type  is  a  copy  of  the  set  of  possible  values  for  the  parent  type. 

4)  Explicit  type  conversion  of  a  value  of  the  parent  type  into  the  corresponding  value  of  the  derived  type  is 
allowed  and  vice  versa.  (In  Ada/SQL  as  in  Ada,  explicit  type  conversions  may  be  performed  from  any 
numeric  type  to  any  numeric  type  and  from  any  string  type  to  any  string  type.  For  Level  1  Ada/SQL, 
then,  the  additional  explicit  type  conversion  capability  provided  for  derived  types  affects  only 
enumeration  types.  Explicit  type  conversion  from  one  enumeration  type  to  another  may  be  performed  if 
one  of  the  two  types  is  derived  from  the  other,  directly  or  indirectly,  or  if  there  exists  a  third  type  from 
which  both  types  are  derived,  directly  or  indirectly.) 

5)  For  each  enumeration  literal  of  the  parent  type  (if  applicable),  there  is  a  corresponding  enumeration 
literal  for  the  derived  type. 

General  Rules 

None. 
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5.5.6.  <constraint> 


Function 


Define  possible  constraints  for  a  data  type. 

Format 

<  constraint*  ::= 

<range  constraint* 

I  <floating  point  constraint* 

I  <index  constraint 

Syntax  Rules 

1)  A  < range  constraint*  specifies  the  bounds  of  the  values  a  type  may  contain. 

2)  A  <floating  point  constraint*  specifies  the  minimum  number  of  significant  decimal  digits  for  a  real  type 
and  possibly  a  <range  constraint*. 

3)  An  < index  constraint*  specifies  the  data  type  of  the  index  of  an  array  and  the  bounds  of  the  index. 

General  Rules 
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5.5.7.  crange  constraint 

Function 

Define  a  range  constraint  for  a  data  type. 

Format 

<range  constraint :  := 
range  <range> 

<range>  ::= 

<range  literai>  ..  <range  literal> 

< range  literal>  ::= 

[  + 1  -  ]  <numeric  !iterai> 

I  enumeration  literal> 

Syntax  Rules 

1)  A  <range>  specifies  a  subset  of  values  of  a  scalar  type.  The  <range>  L..R  specifies  the  values  from  L  to 
R  inclusive  if  the  relation  L  <=  R  is  true.  The  values  L  and  R  are  called  the  lower  bound  and  upper 
bound  of  the  <range>,  respectively.  A  value  V  is  said  to  satisfy  a  <range  constraint  if  it  belongs  to  the 
<raitge>;  the  value  V  is  said  to  belong  to  the  <range>  if  the  relations  L  <=  V  and  V  <=  R  are  both 
TRUE.  A  null  <range>  is  a  <range>  for  which  the  relation  R  <  L  is  TRUE;  no  value  belongs  to  a  null 
<range>. 

2)  If  a  <range  constraint  is  used  in  a  <subtype  indication>,  either  directly  or  as  part  of  a  <floating  point 
constraint,  the  type  of  the  <range  literal>  (converted  from  a  universal  type,  if  necessary)  must  be  the 
same  as  the  base  type  of  the  <type  mailt  of  the  <subtype  indication.  A  <range  constraint  is 
compatible  with  a  subtype  if  each  bound  of  the  <range>  belongs  to  the  subtype,  or  if  the  <range 
constraint  defines  a  null  <range>;  otherwise  the  <range  constraint  is  not  compatible  with  the  subtype. 
A  crange  constraint  on  a  subtype  shall  be  a  subset  of  the  <range  constraint  of  the  <subtype 
indicators 

General  Rules 

None. 
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5.5.8.  < floating  point  constraint> 

Function 

Define  a  floating  point  constraint  for  a  real  data  type. 

Format 

<floating  point  constraint  ::= 

<floating  accuracy  definition>  [<range  constraint] 

<  floating  accuracy  definition>  ::= 
digits  <numeric  literal> 

Syntax  Rules 

1)  For  <floating  accuracy  definitiort,  the  <numeric  literal>  shall  be  a  positive  integer  (nonzero). 

2)  The  <numeric  literal>  specifies  the  minimum  number  of  significant  decimal  digits  that  the 
representation  of  the  real  type  being  defined  must  provide. 

3)  Each  bound  of  the  <range>  of  the  <range  constraint  (if  used)  shall  be  of  a  real  type. 

General  Rules 
None. 
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5.5.9.  <index  const  rain  t> 

Function 

Define  an  index  constraint  for  an  array  data  type. 

Format 

<index  constraint  ::= 

(<range>) 

I  (<subtype  indication) 

Syntax  Rules 

1) The  <index  constrain t>  determines  the  range  of  possible  values  for  the  index  of  an  array  type,  and 
thereby  the  corresponding  array  bounds. 

2)  The  cindex  constraint  specifies  the  type  of  the  array  index,  which  in  Level  1  Add  SQL  must  be  an 
integer  type. 

3)  The  <subtype  indication  may  only  be  the  <type  mark>  of  an  integer  type. 

General  Rules 
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5.5.10.  <subtype  indication> 

Function 

Reference  another  (possibly  constrained)  type  or  subtype. 

Format 

<subtype  indication  ::= 

<type  marlo  [  <constraira>  ] 

<type  marlo  ::= 

[  <package  name> .  ]  <type  identifier* 

Syntax  Rules 

1)  The  <type  marlo  must  previously  have  been  defined  with  a  <type  declaration  or  a  <subtype 
declaration. 

2)  Standard  Ada  visibility  rules  apply  to  the  use  or  omission  of  the  <package  name>  within  the  <type 
marlo. 

General  Rules 

None. 
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5.6.  <value  specification 

Function 

Indicate  program  values,  indicate  whether  or  not  the  values  are  null,  implement  the  keyword  USER. 

Format 

<value  specifications*  ::= 

<program  value> 

I  <program  value  with  indicator 

<program  value >  ::= 

<Ada  program  object> 

I  <literal> 

I  USER 

<program  value  with  indicator*  ::= 

INDICATOR  (  <program  value>  [ ,  <dndicator  variable>  ] ) 

Syntax  Rules 

1)  A  <value  specificadon>  specifies  a  value  that  is  not  selected  from  a  table. 

2)  An  <dndicator  variable>  is  a  program  variable,  constant,  or  literal  of  type  INDICATOR_VARLABLE, 
which  is  an  enumeration  type  with  values  of  NULL_ VALUE  and  NOT_NULL. 

3)  An  <Ada  program  object>  is  a  program  variable  defined  within  a  ^variable  package;*,  of  a  type 
appropriate  for  the  database  column  being  accessed. 

4)  The  data  type  of  USER  is  USER_AUTHORIZATION_IDENTIFIER,  defined  in  the  DATABASE 
package. 

5)  The  data  type  of  a  <program  value  with  indicator*  is  the  same  as  that  of  the  contained  <program  value>. 

Level  l  Implementation  Rules 

1)  Null  values  shall  not  be  used  with  UNIFY. 

General  Rules 

1)  If  a  <value  specification>  contains  an  cindicator  variable:*  and  the  value  of  the  <indicator  variable:*  is 
NULL_ VALUE,  then  the  value  specified  by  the  <value  specification>  is  null.  Otherwise,  the  value 
specified  by  a  <value  specifications*  is  the  value  of  the  contained  <program  value;*. 

2)  The  value  specified  by  a  <literal>  is  the  value  represented  by  that  <literal>. 

3)  The  value  specified  by  USER  is  indicative  of  the  user  executing  the  program. 
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5.7.  <column  specification> 


Function 


Reference  a  named  column. 

Format 

ccolumn  specification>  ::= 

[  <qualifier>.  ]  <column  name> 

<qualifier>  ::= 

<tabie  name> 

I  correlation  name> 

Syntax  Rules 

1)  A  column  specification>  references  a  named  column.  The  meaning  of  a  reference  to  a  column  depends 
on  the  context. 

2)  Let  C  be  the  column  name>  of  the  column  specifications 

3)  Case: 

a)  If  a  column  specification*  contains  a  <qualifier>,  then  the  <column  specification*  shall  appear 
within  the  scope  of  one  or  more  <table  name>s  or  correlation  names>s  equal  to  that 
<qualifier>.  If  there  is  more  than  one  such  <table  name>  or  correlation  name>,  then  the  one 
with  the  most  local  scope  is  specified.  The  table  associated  with  the  specified  <table  name>  or 
correlation  name>  shall  include  a  column  whose  column  name>  is  C. 


b)  If  a  column  specification>  does  not  include  a  <qualifier>,  then  it  shall  be  contained  within  the 
scope  of  one  or  more  <table  name>s  or  correlation  name>s.  Of  these,  let  the  phrase  "possible 
qualifiers"  denote  those  <table  name>s  and  conelahon  name>s  whose  associated  table  includes 
a  column  whose  column  name>  is  C.  There  shall  be  exactly  one  possible  qualifier  with  the  most 
local  scope,  and  that  <table  name>  or  <qualifier>  is  implicitly  specified. 

Note:  the  "scope”  of  a  <table  name>  or  correlation  name>  is  specified  in  5.20,  "<from  clause>”,  8.5, 
”<delete  statement:  searched>",  and  8.12,  "cpdate  statement:  searched>" 

4)  If  a  column  specification*  is  contained  in  a  <table  expression*  T  and  the  scope  of  the  implicidy  or 
explicidy  specified  <qualifier>  of  the  column  specification*  is  some  <Ada/SQL  statement*  or  ctable 
expression*  that  contains  the  <table  expression*  T,  then  the  column  specification*  is  an  "outer 
reference"  to  the  table  associated  with  that  <qualifien>. 

5)  Let  T  denote  the  table  associated  with  the  explicidy  or  implicidy  specified  <qualifier>  R.  The  data  type 
of  a  column  specification*  is  the  data  type  of  column  C  of  T. 


General  Rules 

1)  "C"  or  "R.C"  references  column  C  in  a  given  row  of  T. 
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5.8.  <set  function  specification> 


Functioa 

Specify  a  value  derived  by  tbe  application  of  a  function  to  an  argument. 

Format 

<set  function  specification  ::= 

COUNT  ( ’*’) 

I  cdistinct  set  function 
I  <all  set  function> 

<distinct  set  function  ::= 

{  AVG_DISTINCT 
I  MAX_DISTIN  CT 
I  MINJMSTINCT 
I  SUM_DISTINCT 

I  COUNT_DISTINCT  }  ( <coiumn  specification>  ) 

<ail  set  function  ::= 

{  AVG 
I  MIX 
I  MIN 
I  SUM 
I  AVG_ALL 
I  MAX.ALL 
I  MIN_ALL 

I  SUM_ALL  }  ( cvalue  expression  ) 

Syntax  Rules 

1)  The  argument  of  COUNT  (’*’)  and  the  argument  source  of  a  <distinct  set  function  and  <all  set 
function  is  a  table  or  a  group  of  a  grouped  table  as  specified  in  5.19  "ctable  expression”,  5.24 
”<subquery>"  and  5.25  "cquery  specification". 

2)  Let  R  denote  the  argument  or  argument  source  of  a  <set  function  specification. 

3)  The  <coiumn  specification  of  a  <distinct  set  function  and  each  ccolumn  specification  in  the  <value 
expression  of  an  <all  set  function  shall  unambiguously  reference  a  column  of  R  and  shall  not 
reference  a  column  derived  from  a  <set  function  specification. 

4)  Tbe  <value  expression  of  an  <all  set  function  shall  include  a  ccolumn  specification  that  references  a 
column  of  R  and  shall  not  include  a  cset  function  specification.  If  the  ccolumn  specification  is  an 
outer  reference,  then  the  cvalue  expression  shall  not  include  any  operators.  Note:  "outer  reference"  is 
defined  in  5.7  "ccolumn  specification". 

5)  The  value  returned  by  a  set  function,  other  than  a  count  set  function,  is  typed  the  same  as  the  ccolumn 
specification  or  cvalue  expression  argument  of  tbe  set  function.  The  value  returned  by  a  count  set 
function  is  of  type  INTG  defined  in  the  DATABASE  package. 

6)  If  a  cset  function  specification  contains  a  ccolumn  specification  that  is  an  outer  reference,  then  the 
cset  functioa  specification  shall  be  contained  in  a  csubquery>  of  a  chaving  clause>.  Note:  "outer 
reference"  is  defined  in  5.7  "ccolumn  specification". 

7)  Let  T  be  the  data  type  of  tbe  values  that  result  from  evaluation  of  the  ccolumn  specification  or  cvalue 
expression. 

8)  If  SUM  or  AVG  is  specified,  then  T  shall  not  be  a  character  string  or  an  enumeration. 

Level  /  Implementation  Rules 
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1)  <distinct  set  function>s  shall  not  be  used  with  UNIFY. 

2)  The  <value  expression>  in  an  <all  set  function>  shall  not  be  of  a  string  type  with  UNIFY. 


General  Roles 

1)  The  argument  of  a  <distiact  set  function>  is  a  set  of  values.  The  set  is  derived  by  the  elimination  of  any 
null  values  and  any  redundant  duplicate  values  from  the  column  of  R  referenced  by  the  <column 
specifications 

2)  The  argument  of  an  <all  set  function>  is  a  multi-set  of  values.  The  multi-set  is  derived  by  the 
elimination  of  any  null  values  from  the  result  of  the  application  of  the  <value  expression>  to  each  row  of 
R.  The  specification  or  omission  of  _ ALL  does  not  affect  the  meaning  of  an  <all  set  functions 

3)  Let  S  denote  the  argument  of  a  <distinct  set  function>  or  an  <all  set  functions 

4)  Case: 

a)  If  the  <distinct  set  function>  COUNT_DISTINCT  is  specified,  then  the  result  is  the  cardinality 
ofS. 

b)  If  COUNT  (’*’)  is  specified,  then  the  result  is  the  cardinality  of  R. 

c)  If  AVG,  MIX,  MIN,  or  SUM  (with  or  without  _ALL  or  _DISTINCT  suffix)  is  specified  and  S  is 
empty,  then  the  result  is  the  null  value. 

d)  If  MIX  or  MIN  (with  or  without  _ALL  or  _DISTINCT  suffix)  is  specified,  then  the  result  is 
respectively  the  maximum  or  minimum  value  in  S.  These  results  are  determined  using  the 
comparison  rules  specified  in  5.11  "<comparison  predicate:*". 

e)  If  SUM  (with  or  without  _ALL  or  .DISTINCT  suffix)  is  specified,  then  the  result  is  the  sum  of 
the  values  in  S.  The  sum  shall  be  within  the  range  of  the  data  type  of  the  result. 

0  If  AVG  (with  or  without  _ALL  or  .DISTINCT  suffix)  is  specified,  then  the  result  is  the  average 
of  the  values  in  S.  The  sum  of  the  values  in  S  shall  be  within  the  range  of  the  data  type  of  the 
result 
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5.9.  <value  expression 


Funcdoo 

Specify  a  (possibly)  computed  value. 

Format 

<value  expression  ::= 

[  + 1  -  ]  <tenn> 

I  cvalue  expression  +  <term> 

I  -cvalue  expression  -  <term> 

<term>  ::= 

<£actor> 

I  <term>  *  <factor> 

I  <tenn>  /  <factor> 

<factor>  ::= 

<primary> 

<primary>  ::= 

■cvalue  specification 
I  ccolumn  specification 
I  <set  fiinction  specification 
I  ( -cvalue  expression ) 

I  <type  conversion 

Syntax  Rules 

1)  A  -cvalue  expression  that  includes  a  -cdistinct  set  function  shall  not  include  any  dyadic  operators. 

2)  The  first  ccharacteo  of  the  -ctoken  following  a  monadic  operator  shall  not  be  a  plus  or  minus  sign. 

3)  If  the  data  type  of  a  <pnmary>  is  character  string  or  enumeration  ,  then  the  -cvalue  expression  shall  not 
include  any  operators.  The  data  type  of  the  result  is  the  same  as  that  of  the  <primary>. 

4)  The  data  type  of  the  result  of  a  numeric  operation  is  the  same  as  that  of  the  operand(s).  Both  operands  to 
a  dyadic  operation  shall  be  of  the  same  type. 

5)  Note  that  standard  SQL  permits  monadic  "+"  or  operators  before  any  <primary>  used  within  a 
-cvalue  expression.  The  corresponding  Ada  unary_adding_operators  may  be  applied  only  to  an  entire 
simple_expression.  Furthermore,  a  leading  Ada  unary_adding_operator  is  applied  to  the  entire  first  term 
within  a  simple_expression,  while  a  leading  SQL  monadic  operator  in  a  similar  cvalue  expression> 
would  be  applied  to  the  first  cfactor>  within  the  cterm>.  Expressions  written  in  Ada/SQL  are 
interpreted  according  to  Ada  rules.  Due  to  the  nature  of  the  operations,  however,  the  arithmetic  results 
will  be  the  same  as  if  SQL  interpretation  had  been  applied.  Furthermore,  any  SQL  cvalue  expression 
may  be  equivalently  stated  in  Ada,  using  parentheses  or  depending  on  the  properties  of  the  arithmetic 
operators,  even  though  the  Ada  syntax  is  more  restrictive. 

Level  l  Implementation  Rules 

1)  The  +,  -,  *,  and  /  operators  for  database  types  shall  not  be  redefined. 

General  Rules 

1)  If  the  value  of  any  cprimary>  is  the  null  value,  then  the  result  of  the  cvalue  expression  is  the  null 
value. 

2)  If  operators  are  not  specified,  then  the  result  of  the  cvalue  expression  is  the  value  of  the  specified 
cprimary>. 
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3)  When  a  <value  expression  is  applied  to  a  row  of  a  table,  each  reference  to  a  column  of  tbat  table  is  a 
reference  to  the  value  of  that  column  in  that  row. 

4)  The  monadic  arithmetic  operators  +  and  -  specify  monadic  plus  and  monadic  minus,  respectively. 
Monadic  plus  does  not  change  its  operand.  Monadic  minus  reverses  the  sign  of  its  operand. 

5)  The  dyadic  arithmetic  operators  +,  -,  *  and  /  specify  addition,  subtraction,  multiplication,  and  division, 
respectively.  A  divisor  shall  not  be  0. 

6)  The  result  of  an  operation  applied  to  one  or  more  database  values  shall  be  appropriately  representable  by 
the  database  rales. 

7)  Expressions  within  parentheses  are  evaluated  first  and  when  the  order  of  evaluation  is  not  specified  by 
parentheses,  multiplication  and  division  are  applied  before  any  leading  monadic  operator,  which  is 
applied  before  addition  and  subtraction,  and  operators  at  the  same  precedence  level  are  applied  from  left 
to  right 
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5.10.  <predicate> 


Function 

Specify  a  condition  that  can  be  evaluated  to  give  a  truth  value  of  "true",  "false",  or  "unknown". 

Format 

<predicate>  ::= 

<  com  pans  on  predicate> 

I  < between  predicate> 

I  <in  predicate> 

I  <like  predicate> 

I  <null  predicate  > 

I  quantified  predicate  > 

I  <exists  predicate> 

Syntax  Rules 

None. 

General  Rules 

1)  The  result  of  a  <predicate>  is  derived  by  applying  it  to  a  given  row  of  a  table. 
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5.11.  comparison  predicate> 


Functioo 

Specify  a  comparison  of  two  values. 

Format 

< comparison  predicate>  ::= 

<equalify  operator>  (  <value  expression* ,  <right  comparison  operand>  ) 

I  cvalue  exptession>  <ordering  operator*  <nght  comparison  operand* 

<equality  operator*  ::= 

EQINE 

<ordering  operator*  ::= 

<  I  *  I  <=  I  *= 

<right  comparison  operand*  ::= 
cvalue  expression* 

I  <subquery* 

Syntax  Rules 

1) The  <right  comparison  operand*  of  a  comparison  predicate*  may  be  either  a  (possibly  computed) 
value  or  a  <subquery>. 

2)  The  data  types  of  the  first  cvalue  expression*  and  the  cright  comparison  operand*  shall  be  the  same. 
Level  1  Implementation  Rules 

1)  The  c,  >,  <-  and  >=  operators  for  database  types  shall  not  be  redefined. 

General  Rules 

1) Let  x  denote  the  result  of  the  first  cvalue  expression*  and  let  y  denote  the  result  of  the  cright 
comparison  operand*.  The  result  of  a  csubquery*  shall  be  at  most  one  value. 

2)  If  x  or  y  is  the  null  value  or  if  the  result  of  the  csubquery*  is  empty,  then  "cequality  operator*  (x,  y)"  or 
"x  conlering  operator*  y"  is  unknown. 

3)  If  x  or  y  are  nonnull  values,  then  "cequality  operator*  (x,  y)"  or  ”x  cordering  operator*  y"  is  either  true 
or  false: 

"EQ  (x,  y)"  is  true  if  and  only  if  x  and  y  are  equal. 

"NE  (x,  y)"  is  true  if  and  only  if  x  and  y  are  not  equal. 

"x  c  y"  is  true  if  and  only  if  x  is  less  than  y. 

"x  >  y"  is  true  if  and  only  if  x  is  greater  than  y. 

"x  ca  y"  is  true  if  and  only  if  x  is  not  greater  than  y. 

"x  >=  y"  is  true  if  and  only  if  x  is  not  less  than  y. 

4)  Numbers,  integers,  and  reals  are  compared  with  respect  to  their  algebraic  value. 

5)  The  comparison  of  two  character  strings  is  determined  by  the  comparison  of  ccharacter*s  with  the  same 
ordinal  position.  If  the  strings  do  not  have  the  same  length,  then  the  comparison  is  made  with  a 
temporary  copy  of  the  shorter  string  that  has  been  effectively  extended  on  the  right  with  cspace*s  so 
that  it  has  the  same  length  as  the  other  string. 

6)  Two  strings  are  equal  if  all  characters  with  the  same  ordinal  position  are  equal.  If  two  strings  are  not 
equal,  then  their  relation  is  determined  by  the  comparison  of  the  first  pair  of  unequal  characters  from 
the  left  end  of  the  strings.  This  comparison  is  made  with  respect  to  the  ASCII  collating  sequence. 

7)  Ordering  and  comparison  of  enumeration  values  follow  the  order  of  the  corresponding  position  numbers 
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of  the  enumeration  literals. 

8)  Although  "EQ  (x,  y)"  is  unknown  if  both  x  and  y  are  null  values,  in  the  contexts  of  GROUP  BY, 
ORDER  BY  and  DISTINCT,  a  null  value  is  identical  to  or  is  a  duplicate  of  another  null  value. 
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5.11.1.  <type  conversion 

Function 


Specify  die  conversion  of  a  value  from  one  type  to  another. 

Format 

<type  conversion  ::= 

CONYERT_TO. <type  maik>  (  <value  expression* ) 

Syntax  Rules 

1)  The  type  of  the  result  is  the  same  as  the  <type  maik>. 

2)  Numerics  may  be  converted  to  and  from  all  other  numerics.  Strings  may  be  converted  to  and  from  all 
other  strings.  Enumerations  may  be  converted  to  and  from  other  enumerations  when  one  was  derived 
from  the  other  or  when  both  were  derived  from  a  third  enumeration 

3)  The  <value  expression*  shall  contain  at  least  on  database  <column  name>. 

4)  The  conversion  of  derived  types  is  allowed  if  the  cleft  operand>  type  is  derived  from  the  cright 
operand>  type,  direcdy  or  indirectly  or  vice  versa. 

5)  The  ctype  mario  shall  be  the  fully  expanded  name  of  the  result  type  of  the  conversion  This  type  shall 
be  defined  in  one  of  the  cschema  package>s  named  in  the  ccontext  clause;*. 

General  Rules 

1)  For  underlying  DBMSs  not  supporting  strong  data  typing,  type  conversions  merely  affect  comparability 
and  assignability  of  values,  no  type  checking  is  really  performed. 
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5.12.  cbetween  predicate> 


Function 

Specify  a  range  comparison. 

Format 

cbetween  predicate>  ::= 

[  NOT  ]  BETWEEN  (  <test  value>, 

cvalue  expression  AND  cvalue  expression- ) 

<test  value> 

cvalue  expression- 

Syntax  Rules 

1)  The  data  types  of  the  <test  value>  and  the  two  cvalue  expressions  shall  be  the  same. 

General  Rules 

1)  Let  x  denote  the  <test  value>,  and  y  and  z  denote  the  first  and  second  cvalue  expressions,  respectively. 

2)  "BETWEEN  (x,  y  AND  Z)"  has  the  same  result  as  "  x  >=  y  AND  x  c=  Z". 

3)  "NOT  BETWEEN  (x,  y  AND  z)"  has  the  same  result  as  "NOT  (x  c=  y  AND  x  <=  z)". 
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5.13.  <in  predicate> 

Function 


Specify  a  quantified  comparison. 

Format 

<in  predicate>  ::= 

{  IS_IN  I  NOT_IN  } 

(  <value  expression>  ,  {  <subquety>  I  <in  value  list>  |  ) 

<in  value  list>  ::= 

<value  specification>  [  {  or  <value  specification>  (  ...  ] 

Syntax  Rules 

1)  The  data  types  of  the  <value  expression>  and  the  <subquery>  or  all  <value  specification>s  in  the  <in 
value  list>  shall  be  the  same. 

General  Rules 

1)  Let  X  denote  the  result  of  the  <value  expressions  Let  S  denote  the  result  of  the  <subquery>  as  in  a 
quantified  predicates  or  the  values  specified  by  the  <in  value  list>. 

2)  "ISJN  (X,  S)"  has  the  same  result  as  ”EQ  (X,  (ANY  (S))".  "NOT_IN  (X,  S)"  has  the  same  result  as 
"NOT  (IS_IN  (X,  S))". 
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5.14.  dike  predicate> 


Function 


Specify  a  pattern-match  comparisoa 


Format 


-dike  predicate>  ::= 

[  NOT  ]  LIKE  (  <column  specification>  ,  <pattem> 
f ,  ESCAPE  =>  <escape  character*  ] ) 


<pattem> 

<value  specificat  n> 


<escape  character*  ::= 
<value  specificadon> 


Syntax  Rules 


1)  The  <column  specification*  is  the  specification  of  the  column  to  be  tested.  The  <column  specification> 
shall  reference  a  character  string  column. 


2)  The  data  type  of  the  <pattem>  shall  be  the  same  as  that  of  the  ccolumn  specification*. 

3)  The  <escape  character*  shall  reference  a  character  string  with  a  length  of  one,  of  the  same  type  as  the 


pattern. 


Level  1  Implementation  Rules 

1)  An  <escape  character  may  not  be  specified  with  UNIFY. 

2)  The  <pattem>  may  not  include  ?  or  *  characters  with  UNIFY. 


General  Rules 


1)  Let  x  denote  the  value  referenced  by  the  ccolumn  specification>  and  let  y  denote  the  result  of  the  cvalue 
specification*  of  the  <pattem>. 


2)  Case: 


a)  If  an  <e scape  character*  is  specified,  then: 


i)  Let  z  denote  the  result  of  the  cvalue  specification*  of  the  cescape  character*. 


ii)  There  shall  be  a  partitioning  of  the  string  y  into  substrings  such  that  each  substring  is  of 
length  1  or  2,  no  substring  of  length  1  is  the  escape  character  z,  and  each  substring  of 
length  2  is  the  escape  character  z  followed  by  either  the  escape  character  z,  an  underscore 
character,  or  the  percent  sign  character.  In  that  partitioning  of  y,  each  substring  of  length 
2  represents  a  single  occurrence  of  the  second  character  of  that  substring.  Each  substring 
of  length  1  that  is  the  underscore  character  represents  an  arbitrary  character  specifier. 
Each  substring  of  length  1  that  is  the  percent  sign  character  represents  an  arbitrary  string 
specifier.  Each  substring  of  length  1  that  is  neither  the  underscore  character  nor  the 
percent  sign  character  represents  the  character  that  it  contains. 


b)  If  an  <escape  character*  is  not  specified,  then  each  underscore  character  in  y  represents  an 
arbitrary  character  specifier,  each  percent  sign  character  in  y  represents  an  arbitrary  string 
specifier,  and  each  character  in  y  that  is  neither  the  underscore  character  nor  the  percent  sign 
character  represents  itself. 


3)  The  string  y  is  a  sequence  of  the  minimum  number  of  substring  specifiers  such  that  each  <character>  of 
y  is  part  of  exactly  one  substring  specifier.  A  substring  specifier  is  an  arbitrary  character  specifier,  an 
arbitrary  string  specifier,  or  any  sequence  of  <character>s  other  than  an  arbitrary  character  specifier  or 
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an  arbitrary  string  specifier. 

4)  "LIKE  (x,  y)”  is  unknown  if  x  or  y  is  the  null  value.  If  x  and  y  are  nonnull  values,  then  "LIKE  (x,  y)"  is 
either  true  or  false. 

5)  "LIKE  (x,  y)"  is  true  if  there  exists  a  partitioning  of  x  into  substrings  such  that: 

a)  A  substring  of  x  is  a  sequence  of  zero  or  more  contiguous  <character>s  of  x  and  each 
<character>  of  x  is  part  of  exactly  one  substring. 

b)  If  the  n*  substring  specifier  of  y  is  an  arbitrary  character  specifier,  the  n*  substring  of  x  is  any 
single  <character>. 

c)  If  the  n*  substring  specifier  of  y  is  an  arbitrary  string  specifier,  the  n*  substring  of  x  is  any 
sequence  of  zero  or  more  <cbaracter>s. 

d)  If  the  n*  substring  specifier  of  y  is  neither  an  arbitrary  character  specifier  nor  an  arbitrary  string 
specifier,  the  n*  substring  of  x  is  equal  to  that  substring  specifier  and  has  the  same  length  as  that 
substring  specifier. 

e)  The  number  of  substrings  of  x  is  equal  to  the  number  of  substring  specifiers  of  y. 

6)  "NOT  LUCE  (x,  y)"  has  the  same  result  as  "NOT  (LIKE  (X,  y))". 
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5.15.  <null  predicate> 


Function 


Specify  a  test  for  a  null  value. 


Format 


<nuU  predicate>  ::= 

{  IS_NULL  I  IS_NOT_NULL  }  (  <column  specification>  ) 

Syntax  Rules 


Level  1  Implementation  Rules 

1)  <null  predicate>s  shall  not  be  used  with  UNIFY. 

General  Rules 

1)  Let  x  denote  the  value  referenced  by  the  <column  specifications 

2)  ”IS_NULL  (x)"  is  either  tme  or  false. 

3)  "IS_NULL  (x)”  is  true  if  and  only  if  x  is  the  null  value. 

4)  "IS_NOT_NULL  (x)"  has  the  same  result  as  "NOT  IS.NULL  (x)". 
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5.16.  quantified  predicate> 


Function 

Specify  a  quantified  comparison. 

Format 

quantified  predicate>  ::= 

<equality  operator*  (  <value  expression*  ,  quantified  subquery>  ) 

I  <value  expression*  <ordering  operator*  quantified  subquery* 

quantified  subquery*  ::= 
quantifier*  ( <subquery> ) 

quantifier*  ::= 

<all> 

I  <some> 

<all>  ::= 

ALLL 

<some>  ::= 

SOME 
I  ANY 

Syntax  Rules 

1)  The  data  types  of  the  evalue  expression*  and  the  quantified  subquery*  shall  be  the  same. 

Level  1  Implementation  Rules 

1)  <qualified  predicate>s  shall  not  be  used  with  UNIFY. 

General  Rules 

1)  Let  X  denote  the  result  of  the  <value  expression*  and  let  S  denote  the  result  of  the  <subquery>. 

2)  The  result  of  "<equality  operator*  (  X,  quantifier*  S  )"  or  "X  cordering  operator*  quantifier*  S"  is 
derived  by  the  application  of  the  implied  comparison  predicate*  "equality  operator*  (X,  S)"  or  ”X 
cordering  operator*  S"  to  every  value  in  S. 

3)  Case: 

a)  If  S  is  empty  or  if  the  implied  comparison  predicate*  is  true  for  every  value  s  in  S,  then 
"equality  operator*  (X,  call*  S)"  and  "X  cordering  operator*  call*  S"  are  true. 

b)  If  the  implied  comparison  predicate*  is  false  for  at  least  one  value  s  in  S,  then  "equality 
operator*  (X,  call*  S)"  and  "X  cordering  operator*  call*  S”  are  false. 

c)  If  the  implied  comparison  predicate*  is  true  for  at  least  one  value  s  in  S,  then  "equality 
operator*  (X,  csome*  S)"  and  "X  cordering  operator*  csome*  S"  are  true. 

d)  If  S  is  empty  or  if  the  implied  comparison  predicate*  is  false  for  every  value  s  in  S.  then 
"equality  operator*  (X,  csome*  S)"  and  "X  cordering  operator*  csome*  S"  are  false. 

e)  If  "equality  operator*  (X,  quantifier*  S)"  or  "X  cordering  operator*  quantifier*  S"  is  neither 
true  nor  false,  then  it  is  unknown. 
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5.17.  <exists  predicate> 

Function 

Specify  a  test  for  an  empty  set 

Format 

<exists  predicate >  ::= 

EXISTS  ( <subquery> ) 

Syntax  Rules 

None. 

Level  1  Implementation  Rules 

I)  <exists predicate>s  shall  not  be  used  with  UNIFY. 

General  Rules 

1)  Let  S  denote  the  result  of  the  <subquery>. 

2)  "EXISTS  (S)M  is  either  true  or  false. 

3)  "EXISTS  (S)"  is  true  if  and  only  if  S  is  not  empty. 
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5.18.  <search  condition> 

Function 

Specify  a  condition  that  is  "true",  ’’false”,  or  ''unknown''  depending  on  the  result  of  applying  boolean  operators  to 

specified  conditions. 

Format 

<search  condi tion> 

< boolean  factor*  [  {  AND  <boolean  factor>  } ...  ] 

1  < boolean  factor>  [  (  OR  <boolean  factor*  } ...  ] 

<  boolean  factor*  ::= 

[  NOT  ]  <boolean  primary> 

< boolean  primary>  ::= 

<predicate> 

I  (  <search  condi tion> ) 

Syntax  Rules 

1)  Combinations  of  AMDs  and  ORs  shall  be  parenthesized  to  clearly  show  order  of  evaluation.  <This 
differs  from  SQL  syntax  but  is  required  by  Ada  syntax>. 

2)  A  ccolumn  specification>  or  <value  expression*  specified  in  a  <search  condition>  is  directly  contained 
in  that  <search  coodition>  if  the  <column  specification*  or  <value  expression>  is  not  specified  within  a 
<set  function  specification>  or  a  <subquery>  of  the  <search  condition>. 

General  Rules 

1) Tbe  result  is  derived  by  the  application  of  the  specified  boolean  operators  to  the  conditions  that  result 
from  the  application  of  each  specified  <predicate>  to  a  given  row  of  a  table  or  a  given  group  of  a 
grouped  table.  If  boolean  operators  are  not  specified,  then  the  result  of  the  <search  condition>  is  the 
result  of  the  specified  <predicate>. 

2)  NOT  (true)  is  false,  NOT  (false)  is  true,  and  NOT  (unknown)  is  unknowa  AND  and  OR  are  defined  by 
the  following  truth  tables: 


AND 

True 

False 

Unknown 

True 

True 

False 

Unknown 

False 

False 

False 

False 

Unknown 

Unknown 

False 

Unknown 

OR 

True 

False 

Unknown 

True 

True 

True 

True 

False 

True 

False 

Unknown 

Unknown 

True 

Unknown 

Unknown 

5)  Expressions  within  parentheses  are  evaluated  first.  When  used  without  parentheses,  NOT  is  applied 


54 


DRAFT 


j>Vi\VAVi 


f 

before  AND  or  OR.  Unparenthesized  operators  of  the  same  type  are  applied  from  left  to  right. 

6)  When  a  <search  condition>  is  applied  to  a  row  of  a  table,  each  reference  to  a  column  of  that  table  by  a 
<column  specification^1  directly  contained  in  the  <search  condi tion>  is  a  reference  to  the  value  of  that 
A  column  in  that  row. 
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5.19.  <table  expression 

Function 

Specify  a  table  or  a  grouped  table. 

Format 

<table  expression  ::= 

<from  clauso 
[ ,  <wheie  clauso  ] 

[ ,  <  group  by  clauso  ] 

[ ,  <baving  clauso  ] 

Syntax  Rules 

1)  If  the  table  identified  in  the  <from  clauso  is  a  grouped  view,  then  the  <table  expression>  shall  not 
contain  a  <where  clauso,  <group  by  clause>,  or  <having  clauso. 

General  Rules 

1)  If  all  optional  clauses  are  omitted,  then  the  table  is  the  result  of  the  <from  clauso.  Otherwise,  each 
specified  clause  is  applied  to  the  result  of  the  previously  specified  clause  and  the  table  is  the  result  of  the 
application  of  the  last  specified  clause.  The  result  of  a  ctable  expression>  is  a  derived  table  in  which  the 
n*  column  inherits  the  description  of  the  n*  column  of  the  table  specified  by  the  <from  clauso. 
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5.20.  <from  clause> 


Function 

Specify  a  table  derived  from  ooe  or  more  named  tables. 

Format 

<from  clause>  ::= 

FROM  *x  <table  reference>  t  {  &  <table  reference>  } ...  ] 

cable  reference>  ::= 

[  correlation  name> .  ]  <table  name> 

Syntax  Rules 

1)  A  Cable  name>  specified  in  a  cable  reference>  is  exposed  in  the  containing  <from  clause>  if  and  only 
if  that  cable  re  fere  nee  >  does  not  specify  a  correlation  name>. 

2)  A  Cable  name>  that  is  exposed  in  a  <from  clause>  shall  not  be  the  same  as  any  other  Cable  name>  that 
is  exposed  in  that  <from  clausex 

3)  A  correlation  namex  specified  in  a  cable  reference>  shall  not  be  the  same  as  any  other  correlation 
name>  specified  in  the  containing  <from  clause>,  and  shall  not  be  the  same  as  the  cable  identifier>  of 
any  cable  name>  that  is  exposed  in  the  containing  <from  clause>. 

4)  The  scope  of  correlation  namexs  and  exposed  Cable  name>s  specified  in  a  <from  clause>  is  the 
innermost  <subquery>,  <query  specificadon>,  or  <select  statementx  that  contains  the  cable 
expression  in  which  the  <£rom  clausex  is  contained.  A  cable  name>  that  is  specified  in  a  <from 
clause>  has  a  scope  defined  by  that  <from  clause>  if  and  only  if  the  cable  name>  is  exposed  in  that 
<from  clausex 

5)  If  the  table  identified  by  cable  name>  is  a  grouped  view,  then  the  <from  clause>  shall  contain  exactly 
one  cable  reference>. 

6)  Case: 

a)  If  the  <from  clause>  contains  a  single  cable  name>,  then  the  description  of  the  result  of  the 
<from  clause>  is  the  same  as  the  description  of  the  table  identified  by  that  cable  namex 

b)  If  the  efrom  clause>  contains  more  than  one  cable  name>,  then  the  description  of  the  result  of 
the  <from  clause>  is  the  concatenation  of  the  descriptions  of  the  tables  identified  by  those  ctable 
name>s,  in  the  order  in  which  the  cable  name>s  appear  in  the  efirom  clausex 

7)  In  Ada/SQL,  a  correlation  name>  is  actually  a  package  instantiated  from  the  generic  package  specific 
to  each  cable  namex.  In  order  to  define  a  correlation  namex,  the  appropriate  generic  package  must  be 
instantiated,  in  one  of  the  two  following  ways: 

package  correlation  namex  is  new 

Cable  identifier>_CORRELATION_NAME; 

package  correlation  namex  is  new 
cauthorization  identifierx_cable  identifierx_CORRELATION_NAME; 

Note  that  the  generic  packages  are,  in  general,  named  cable  namex_CORRELATION_NAME,  except 
that  an  cauthorization  identifierx  used  within  a  Cable  namex  is  separated  from  the  cable  identifierx  by 
an  underscore. 

Although  correlation  namexs  are  specifically  declared  to  pertain  to  specific  tables,  the  same 
correlation  namex  may  be  reused  within  different  scopes  of  the  same  statement,  to  refer  to  different 
instances  of  the  same  table. 

General  Rules 
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1)  The  specification  of  a  correlation  name>  or  exposed  cable  name>  in  a  Cable  reference>  defines  that 
correlation  name>  or  cable  name>  as  a  designator  of  the  table  identified  by  the  cable  name>  of  that 
cable  referencex 

2)  Case: 

a)  If  the  <from  clause>  contains  a  single  cable  name>,  then  the  result  of  the  <£rom  clause>  is  the 
table  identified  by  that  cable  name>. 

b)  If  the  <from  clause>  contains  more  than  one  cable  name>,  then  the  result  of  the  <from  clause> 
is  the  extended  Cartesian  product  of  the  tables  identified  by  those  cable  names>s.  The  extended 
Cartesian  product,  R,  is  the  multi-set  of  all  rows  r  such  that  r  is  the  concatenation  of  a  row  from 
each  of  the  identified  tables  in  the  order  in  which  they  are  identified.  The  cardinality  of  R  is  the 
product  of  the  cardinalities  of  the  identified  tables.  The  ordinal  position  of  a  column  in  R  is  n+s, 
where  n  is  the  ordinal  position  of  that  column  in  the  named  table  T  from  which  it  is  derived  and  s 
is  the  sum  of  the  degrees  of  the  tables  identified  before  T  in  the  <from  clause>. 
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5.21.  <where  clause> 


Function 

Specify  a  table  derived  by  the  application  of  a  <search  condition>  to  the  result  of  the  preceding  cfrom  clause>. 

Format 

<where  dause>  ::= 

WHERE  =>  <searcfa  condi  tion> 

Syntax  Rules 

1)  Let  T  denote  the  description  of  the  result  of  the  preceding  <from  clause>.  Each  <column  specification> 
directly  contained  in  the  <search  condition>  shall  unambiguously  reference  a  column  of  T  or  be  an  outer 
reference.  Note:  "outer  reference  is  defined  in  5.7  "<column  specification^'. 

2)  A  cvalue  expression  directly  contained  in  the  <search  condition>  shall  not  include  a  reference  to  a 
column  derived  from  a  function. 

3)  If  a  <value  expression  directly  contained  in  the  csearch  condition  is  a  cset  function  specification:*, 
then  the  cwbere  clause>  shall  be  contained  in  a  chaving  clause>  and  the  ccolumn  specification>  in  the 
cset  function  specification>  shall  be  an  outer  reference. 

General  Rules 

1)  Let  R  denote  the  result  of  the  cfrom  clausex 

2)  The  csearch  condition>  is  applied  to  each  row  of  R.  The  result  of  the  cwhere  clause>  is  a  table  of  those 
rows  of  R  for  which  the  result  of  the  csearch  condition>  is  true. 

3)  Each  csubquery>  in  the  csearch  condition>  is  effectively  executed  for  each  row  of  R  and  the  results 
used  in  the  application  of  the  csearch  conditioro  to  the  given  row  of  R.  If  any  executed  csubquety> 
contains  an  outer  reference  to  a  column  R,  then  the  reference  is  to  the  value  of  that  column  in  the  given 
row  of  R. 
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5.22.  <group  by  clause> 


Function 

Specify  a  grouped  table  derived  by  tbe  application  of  the  <group  by  clause>  to  the  result  of  the  previously  specified 
clause. 

Format 

<group  by  clause>  ::= 

GROUP_BY  =>  <column  specification>  [  {  &  <column  specification>  }  ...  ] 

Syntax  Rules 

1)  Let  T  denote  the  description  of  the  result  of  the  preceding  <£rom  clause>  or  <where  clause>. 

2)  Each  <column  specification>  in  the  <group  by  clause>  shall  unambiguously  reference  a  column  of  T.  A 
column  referenced  in  a  < group  by  clause>  is  a  grouping  columa 

General  Rules 

1)  Let  R  denote  the  result  of  the  preceding  <from  clause>  or  cwhere  clause>. 

2)  The  result  of  the  <group  by  clause>  is  a  partitioning  of  R  into  a  set  of  groups.  The  set  is  the  minimum 
number  of  groups  such  that,  for  each  grouping  column  of  each  group  of  more  than  one  row,  all  values  of 
that  grouping  column  are  identical. 

I  3)  Every  row  of  a  given  group  contains  the  same  value  of  a  given  grouping  column.  When  a  <search 

1  condinoto  or  <value  expressioro  is  applied  to  a  group,  a  reference  to  a  grouping  column  is  a  reference 

!  to  that  value. 


> 
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5.23.  <having  clause> 


Fanctk» 

Specify  a  restriction  on  the  grouped  table  resulting  from  the  previous  cgroup  by  clause>  or  <from  clause>  by 

eliminating  groups  not  meeting  the  <search  conditions. 

Format 

-chaving  clauses  ::= 

HAVING  =s  <search  conditions 

Syntax  Rules 

1)  Let  T  denote  the  description  of  the  result  of  the  preceding  <from  clauses,  cwhere  clauses,  or  <group  by 
clauses.  Each  <column  specifications  directly  contained  in  the  <search  conditions  shall 
unambiguously  reference  a  grouping  column  of  T  or  be  an  outer  reference.  Note:  "outer  reference"  is 
defined  in  5.7  "ccolumn  specifications". 

2)  Each  <column  specifications  contained  in  a  csubquerys  in  the  <search  conditions  that  references  a 
column  of  T  shall  reference  a  grouping  column  of  T  or  shall  be  specified  within  a  <set  function 
specifications. 

General  Rules 

1)  Let  R  denote  the  result  of  the  preceding  <from  clauses,  <where  clauses,  or  <group  by  clauses.  If  that 
clause  is  not  a  <group  by  clauses,  the  R  consists  of  a  single  group  and  does  not  have  a  grouping  column. 

2)  The  csearch  conditions  is  applied  to  each  group  of  R.  The  result  of  the  <having  clauses  is  a  grouped 
table  of  those  groups  of  R  for  which  the  result  of  the  <search  conditions  is  true. 

3)  When  the  csearch  conditions  is  applied  to  a  given  group  of  R,  that  group  is  the  argument  or  argument 
source  of  each  <set  function  specifications  di reedy  contained  in  the  csearch  conditions  unless  the 
ccolumn  specifications  in  the  cset  function  specifications  is  an  outer  reference. 

4)  Each  csubquerys  in  the  csearch  conditions  is  effectively  executed  for  each  group  of  R  and  the  result 
used  in  the  application  of  the  csearch  conditions  to  the  given  group  of  R.  If  any  executed  csubquerys 
contains  an  outer  reference  to  a  column  of  R,  then  the  reference  is  to  the  values  of  that  column  in  the 
given  group  of  R. 
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5.24.  <subquery> 


Function 

Specify  a  multi-set  of  values  derived  from  the  result  of  a  <table  expressions 

Format 

<subquery>  ::= 

[  SELEC I  SELECT.ALL  I  SELECT.DISTINCT  ] 

(  <subquery  result  specification>  ,  <table  expression>  ) 

<subquery  result  specification>  ::= 
cvalue  expression> 

I 

Syntax  Rules 

1) The  applicable  <privilege>s  for  each  <table  name>  contained  in  the  <table  expression>  shall  include 
SELEC.  Note:  the  "applicable  <privileges> "  for  a  <table  name>  will  be  defined  in  "<privilege 
definition>"  for  later  levels  of  AdatSQL.  In  Level  1,  privileges  are  as  defined  to  the  underlying  DBMS. 

2)  Case: 

a)  If  the  <subquery  result  specification>  is  specified  in  a  <subquery>  of  any  <predicate>  other 
than  an  <exists  predicates  then  the  degree  of  the  <table  expression>  shall  be  1,  and  the 
<subquery  result  specification>  is  equivalent  to  a  cvalue  expression>  consisting  of  a  ccolumn 
specification>  that  references  the  sole  column  of  the  ctable  expressions 

b)  If  the  csubquery  result  specification>  is  specified  in  a  <subquery>  of  an  cexists  predicates, 
then  the  csubquery  result  specification>  is  equivalent  to  an  arbitrary  cvalue  expression>  that 
does  not  include  a  cset  function  specification>  and  that  is  allowed  in  the  csubquerys 

3)  The  data  type  of  the  values  of  the  csubquery>  is  the  data  type  of  the  implicit  or  explicit  cvalue 
expressions 

4)  Let  R  denote  the  result  of  the  ctable  expressions 

5)  Each  ccolumn  specification>  in  the  cvalue  expressioro  shall  unambiguously  reference  a  column  of  R. 

6)  If  R  is  a  grouped  view,  then  the  csubquery  result  specification>  shall  not  contain  a  cset  function 
specifications 

7)  If  R  is  a  grouped  table,  then  each  ccolumn  specification>  in  the  cvalue  expression>  shall  reference  a 
grouping  column  or  be  specified  within  a  cset  function  specifications  If  R  is  not  a  grouped  table  and 
the  cvalue  expression>  includes  a  cset  function  specifications  then  each  ccolumn  specification>  in  the 
cvalue  expression  shall  be  specified  within  a  cset  function  specifications 

8)  A  csubquerys  excluding  any  csubquery>  contained  within  it,  shall  contain  at  most  one  use  of  an 
Ada/SQL  keyword  ending  in  DISTINCT  (SELECT.DISTINCT,  AVG_DISTINCT,  MAX.DISTINCT, 
MIN_DISTINCT,  SUMJDISTINCT,  COUNT_DISTINCT). 

9)  If  a  csubquery>  is  specified  in  a  ccomparison  predicates  then  the  ctable  expression>  shall  not  contain  a 
cgroup  by  clause>  or  a  chaving  clause>  and  shall  not  identify  a  grouped  view. 

General  Rules 

1)  If  R  is  not  a  grouped  table  and  the  cvalue  expression>  includes  a  cset  function  specifications  then  R  is 
the  argument  or  argument  source  of  each  cset  function  specification>  in  the  cvalue  expression>  and  the 
result  of  the  csubquery>  is  the  value  specified  by  the  cvalue  expressions 

2)  If  R  is  not  a  grouped  table  and  the  cvalue  expression>  does  not  include  a  cset  function  specification^ 
then  the  cvalue  expression>  is  applied  to  each  row  of  R  yielding  a  multi-set  of  n  values,  where  n  is  the 
cardinality  of  R.  If  SELECT_DISTINCT  is  not  specified,  then  the  multi-set  is  the  result  of  the 
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<subquery>.  If  SELECT_DISTINCT  is  specified,  then  the  result  of  the  <subquery>  is  the  set  of  values 
derived  from  that  multi-set  by  the  elimination  of  all  redundant  duplicate  values. 

3)  If  R  is  a  grouped  table,  then  the  <value  expression>  is  applied  to  each  group  of  R  yielding  a  multi-set  of 
n  values,  where  n  is  the  number  of  groups  in  R.  When  the  <value  expression>  is  applied  to  a  given 
group  of  R,  that  group  is  the  argument  or  argument  source  of  each  <set  function  specification>  in  the 
<value  expressions  If  SELECT_DISTTNCT  is  not  specified,  then  the  multi-set  is  the  result  of  the 
<subquery>.  If  SF.1  JECT_D1STINCT  is  specified,  then  the  result  of  the  <subquery>  is  the  set  of  values 
derived  from  that  multi-set  by  the  elimination  of  any  redundant  duplicate  values. 
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5.25.  <query  specification 


Function 

Specify  a  table  derived  from  the  result  of  a  <table  expressions 

Format 

<query  specifications  ::= 

[  SELEC I  SELECT_ALL  I  SELECT_DISTINCT  ] 

( <select  liso ,  <table  expression> ) 

<select  lists  ::= 

<value  expression>  [  {  &  <value  expression>  (  ...  ] 

1 

Syntax  Rules 

1) The  applicable  cprivilegess  for  each  <table  name>  contained  in  the  <table  expression>  shall  include 
SELEC.  Note:  the  "applicable  <privileges>"  for  a  <table  name>  will  be  defined  in  "<privilege 
definition^'  for  later  levels  of  Ada!  SQL.  In  Level  1,  privileges  are  as  defined  to  the  underlying  DBMS. 

2)  Let  R  denote  the  result  of  the  <table  expressions 

3)  The  degree  of  the  table  specified  by  a  <query  specification>  is  equal  to  the  cardinality  of  the  <select 
lists. 

4)  The  <select  liso  is  equivalent  to  a  <value  expression>  sequence  in  which  each  <value  expression>  is 
a  ccolumn  specification  that  references  a  column  of  R  and  each  column  of  R  is  referenced  exactly 
once.  The  columns  are  referenced  in  the  ascending  sequence  of  their  ordinal  position  within  R. 

5)  Each  -ccolumn  specification>  in  each  <value  expression>  shall  unambiguously  reference  a  column  of 
R.  A  <query  specifications,  excluding  any  csubquerys  contained  within  it,  shall  contain  at  most  one  use 
of  an  Ada/SQL  keyword  ending  in  DISTINCT  (SELECT.DISTINCT,  AVG.DISTINCT, 
MAX  DISTINCT,  MIN_DISTINCT,  SUM_DISTINCT,  COUNT_DISTINCr). 

6)  If  R  is  a  grouped  view,  then  the  <select  liso  shall  not  contain  a  <set  function  specifications 

7)  If  R  is  a  grouped  table,  then  each  ccolumn  specification>  in  each  cvalue  expression>  shall  reference  a 
grouping  column  or  be  specified  within  a  cset  function  specification>.  If  R  is  not  a  grouped  table  and 
any  cvalue  express; oo>  includes  a  cset  function  specifications,  then  every  cvalue  expression>  shall  be 
specified  within  a  cset  function  specifications 

8)  Each  column  of  the  table  that  is  the  result  of  a  cquery  specification>  has  the  same  data  type  as  the 
cvalue  expressioa>  from  which  the  column  was  derived. 

9)  If  the  n*  cvalue  expression>  in  the  cselect  liso  consists  of  a  single  ccolumn  specifications,  then  the  n* 
column  of  the  result  is  a  named  column  whose  ccolumn  name>  is  that  of  the  ccolumn  specifications 
Otherwise,  the  n*  column  is  an  unnamed  column. 

10)  A  column  of  the  table  that  is  the  result  of  a  cquery  specification>  is  constrained  to  contain  only  nonnull 
values  if  and  only  if  it  is  a  named  column  that  is  constrained  to  contain  only  nonnull  values. 

1 1)  A  cquery  specifications  is  updatable  if  and  only  if  the  following  conditions  hold: 

a)  SELECT_DIS7TNCI  is  not  specified. 

b)  Every  cvalue  expressions  in  the  cselect  Lists  consists  of  a  ccolumn  specifications. 

c)  The  cfrom  clauses  of  the  ctable  expressions  specifies  exactly  one  ctable  references,  and  that 
ctable  references  refers  to  an  updatable  table. 

d)  The  cwhere  clauses  of  the  ctable  expressions  does  not  include  a  csubquerys. 

e)  The  ctable  expressions  does  not  include  a  cgroup  by  clauses  or  a  chaving  clauses. 
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General  Rules 


1)  If  R  is  not  a  grouped  table  and  the  <select  list>  includes  a  <set  function  specification>,  then  R  is  the 
argument  or  argument  source  of  each  <set  function  specification>  in  the  <select  list>  and  the  result  of 
the  <query  specifications  is  a  table  consisting  of  one  row.  The  0th  value  of  the  row  is  the  value 
specified  by  die  n*  <vaiue  expressions. 

2)  If  R  is  not  a  grouped  table  and  the  <select  list>  does  not  include  a  <set  function  specifications,  then  each 
<value  expressions  is  applied  to  each  row  of  R  yielding  a  table  of  m  rows,  where  m  is  the  cardinality  of 
R.  The  n“  column  of  the  table  contains  the  values  derived  by  the  applications  of  the  n*  <value 
expressions  If  SELECT_D[STTNCT  is  not  specified,  then  the  table  is  the  result  of  the  <query 
specifications  If  SELECT_DISTINCT  is  specified,  then  the  result  of  the  <query  specification>  is  the 
table  derived  from  that  table  by  the  elimination  of  any  redundant  duplicate  rows. 

3)  If  R  is  a  grouped  table  that  has  zero  groups  and  some  <value  expression  in  the  <select  lists  is  a 
ccolumn  specifications  then  the  result  of  the  <query  specification>  is  an  empty  table.  If  R  is  a  grouped 
table  that  has  zero  groups  and  every  cvalue  expression>  in  the  <select  lists  is  a  <set  function 
specifications,  then  the  result  of  the  <query  specifications  is  a  table  having  one  row.  The  n111  value  in 
that  row  is  the  result  of  the  n*  <set  function  specifications  in  the  <select  lists. 

4)  If  R  is  a  grouped  table  that  has  one  or  more  groups,  then  each  <value  expressions  is  applied  to  each 
group  of  R  yielding  a  table  of  m  rows,  where  m  is  the  number  of  groups  in  R.  The  nth  column  of  the 
table  contains  the  values  derived  by  the  applications  of  the  0th  <value  expressions.  When  a  <value 
expressions  is  applied  to  a  given  group  of  R,  that  group  is  the  argument  or  argument  source  of  each  <set 
function  specifications  in  the  <value  expressions.  If  SELECT_DISTINCT  is  not  specified,  then  the 
table  is  the  result  of  the  <query  specifications.  If  SELECT_DISTTNCT  is  specified,  then  the  result  of 
the  <query  specifications  is  the  table  derived  from  that  table  by  the  elimination  of  any  redundant 
duplicate  rows. 

5)  A  row  is  a  duplicate  of  another  row  if  and  only  if  all  pairs  of  values  with  the  same  ordinal  position  are 
identical. 
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6.  Schema  Definition  Language 

6.1.  <schema> 

Function 

Define  a  <schema>. 

Format 

<schema>  ::=  <scbema  compilation  unit> ... 

<schema  compilation  unit> 

<authonzation  package  compilation  unit> 

I  <schema  package  compilation  unit> 

Syntax  Rules 

1)  The  <schema  compilation  unit>s  within  a  <schema>  need  not  be  part  of  the  same  compilation. 

2)  A  <schema>  shall  contain  exactly  one  authorization  package  compilation  unit>. 

3)  All  <schema  package  compilation  unit>s  referencing  the  same  authorization  package  compilation  unit> 
are  part  of  the  same  <schema>. 

General  Rules 

None. 
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6.1.1.  authorization  package  compilation  unit> 

Function 

Define  an  <authorization  identifier*. 

Format 

eauthorization  package  compilation  unio  ::= 

with  SCHEMA.DEFINmON;  use  SCHEMA_DEFINmON; 
eauthorization  package  spedfication> ; 

< authorization  package  specification>  ::= 
package  identifier*  is 

function  authorization  identifier*  is  new  AUTHORIZATION_IDENTIFIER; 
end  [  <package  simple  name>  ] 

<package  simple  name>  ::=  identifier* 

Syntax  Rules 

1) The  <package  simple  name>,  if  used  within  the  <authorization  package  specification>,  must  repeat  the 
identifier*. 

2)  The  <authorization  identifier*  shall  be  different  from  the  eauthorization  identifier*  of  any  other 
<schema>  in  the  same  environment. 

3)  An  eauthorization  package  specificatiotu*  is  said  to  define  an  authorization_package,  and  the 
identifier*  is  taken  as  the  name  of  that  authorization  package. 

General  Rules 

None. 
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6.1.2.  <schema  package  compilation  unit> 

Function 

Define  a  portion  of  a  <schema>  that  may  be  separately  compiled. 

Format 

<schema  package  compilation  unit>  ::= 
ccoatext  clause  > 

<schema  package  specification> ; 

<scbema  package  spedfication>  ::= 
package  identifier*  is 
[  <use  clause> ...  ] 
package  ADA_SQL  is 
[  <use  clause> ...  ] 

[  <schema  authorization  clause>  ] 

[  <scbema  specification  element> ...  ] 
end  ADA_SQL; 
end  [  <package  simple  name>  ] 

<schema  authorization  clause>  ::= 

SCHEMA_AUTHORIZATION :  IDENTIFIER  :=  <schema  authorization  identifier* ; 

<schema  authorization  identifier*  ::=  < authorization  identifier* 

cschema  specification  element>  ::= 

<type  declaration* 

I  <subtype  declaration* 

I  <table  definition* 

Syntax  Rules 

1)  The  authorization  identifier*  shall  match  one  directly  contained  within  an  authorization  package 
specification*.  The  <schema  package  compilation  unit*  is  said  to  reference  the  < authorization  package 
compilation  unit*  containing  that  <authorization  package  specification*. 

2)  A  <with  clause*  and  a  <use  clause*  of  the  <context  clause*  shall  each  contain  the  name  of  the 
authorization  package  defining  the  authorization  identifier*. 

3)  If  the  schema  package  contains  one  or  more  table  declarations,  it  shall  then  contain  a  <schema 
authorization  clause*,  and  a  <with  clause*  and  a  <use  clause*  of  the  ccontext  clause*  shall  each  name 
SCHEMA_DEFINITION, 

4)  The  <package  simple  name*,  if  used  within  the  <schema  package  specification*,  must  repeat  the 
identifier*. 

3)  The  only  <unit  simple  name*s  that  may  be  used  within  a  <context  clause*  of  a  <schema  package 
compilation  unit*  are  those  of  schema  packages,  plus  the  following  predefined  packages: 
SCHEMA.DEFINmON,  DATABASE. 

Level  l  Implementation  Rules. 

1  )Each  <schema  package  compilation  unit>  shall  be  placed  in  its  own  source  file.  The  name  of  this 
source  file  shall  be  the  same  as  that  of  the  schema  package  defined,  except  that  a  system-dependent 
name  augmentation  may  be  used  to  indicate  that  the  file  contains  Ada  source  code.  This  augmentation 
will  be  defined  for  each  specific  AdaISQL  system. 

General  Rules 
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6.1.3.  <context  clause> 


Function 

Specify  other  packages  required  by  a  package. 

Format 

<  con  text  clause>  ::= 

[  {  <with  clause>  [  <use  clause> ...  ]}...] 

<with  clause >  ::= 

with  <unit  simple  name>  [  {  ,  <unit  simple  name>  )...]; 

<use  clause>  ::= 

use  <package  name>  [  {  ,  <package  name>  }...]; 

Syntax  Rules 

1) The  form  of  cunit  simple  name>  .  ADA_SQL  as  a  <package  name>  is  peimitted  only  if  <unit  simple 
name>  is  the  name  of  a  schema  package,  and  is  not  permitted  within  a  ccontext  clause>. 

2)  A  <unit  simple  name>  contained  within  a  <use  clause>  shall  be  contained  within  a  textually  prior  <with 
clause>. 

Level  I  Implementation  Rules 

1)  The  file  containing  a  schema  package  named  in  a  <context  clause>  shall  be  accessible  using  only  its 
name,  without  any  other  operating  system  dependent  path  information,  at  the  time  the  <context  clause> 
is  processed  by  any  AdaISQL  automated  tool. 

General  Rules 

None. 
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6.1.4.  <type  declaration> 

Function 

Declare  a  data  type. 

Format 

<type  declaration 

<full  type  declaration 

<full  type  declaration;*  ::= 

type  <type  identifier  is  <type  definition ; 

<type  definition  ::= 

<datatype> 

I  <derived  type  definition 

Syntax  Rules 

1)  The  <type  identifier  shall  not  contain  a  _NOT_NULL  or  _NOT_NULL_UNIQUE  suffix. 

2)  The  <type  identifier  is  defined  as  the  name  of  the  type. 

3)  The  <type  identifier  shall  be  different  from  the  <type  identifier  or  <table  name>  defined  by  any  other 
<schema  specification  elemenr  in  the  containing  <schema  package  specification. 

General  Rules 

None. 
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6.1.5.  <subtype  declaration 

Functioo 

Declare  a  data  subtype. 

Format 

<subtype  declaratioa>  ::= 

subtype  <type  identifier*  is  <subtype  indication>  ; 

Syntax  Rules 

1) Case: 

a)  If  the  <type  identifier*  contains  neither  the  _NOT_NULL  nor  the  _NOT_NULL_UNIQUE 
suffix,  then  the  <type  identifier*  within  the  ctype  marie*  of  the  <subtype  indication>  shall  also 
not  contain  either  of  these  suffixes. 

b)  If  the  <type  identifier*  contains  the  _NOT_NULL  suffix,  then: 

i)  The  <type  identifier*  within  the  <type  mario  of  the  <subtype  indication>  shall  not 
contain  any  suffix. 

ii)  The  <identifier>  of  the  <type  identifier*  within  the  <type  mario  of  the  <subtype 
indication>  shall  match  the  identifier*  within  the  <type  identifier*. 

iii)  The  <subtype  indication>  shall  not  contain  a  <constraint>. 

c)  If  the  <type  identifier*  contains  the  _N0T_NTJLL_UN1QUE  suffix,  then: 

i)  The  <type  identifier*  within  the  <type  mario  of  the  <subtype  indication>  shall  either 
contain  no  suffix  or  shall  contain  the  _NOT_NULL  suffix. 

ii) The  identifier*  of  the  <type  identifier*  within  the  <type  mario  of  the  <subtype 
indication>  shall  match  the  identifier*  within  the  <type  identifier*. 

iii)  The  <subtype  indication>  shall  not  contain  a  constraint*. 

2)  The  <type  identifier*  is  defined  as  the  name  of  the  subtype. 

3)  The  <type  identifier*  shall  be  different  from  the  <type  identifieo  or  cable  name>  defined  by  any  other 
<scbema  specification  element*  in  the  containing  <schema  package  specifications 

General  Rules 

None. 
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6.2.  ctable  definition 


Function 

Define  a  table. 

Format 

•ctable  definition*  ::= 
type  -ctable  name>  is 

record 

-ctable  element> ... 

end  record ; 

•ctable  elemeno  ::=  ccolumn  definition>  ; 

Syntax  Rules 

1)  The  ctable  name>  shall  not  contain  an  cauthorization  identifier. 

2)  The  ctable  name>  shall  be  different  from  the  ctable  name>  of  any  other  ctable  definition>  in  the 
containing  cschema>. 

3)  The  ctable  name>  shall  be  different  from  the  ctype  identifier  or  ctable  name>  defined  by  any  other 
cschema  specification  elemenr  in  the  containing  cschema  package  specification>. 

4)  The  description  of  the  table  defined  by  a  ctable  definition>  includes  the  name  ctable  name>  and  the 
column  description  specified  by  each  ccolumn  definition>.  The  i,h  column  description  is  given  by  the 
i*  ccolumn  definitions 

Level  l  Implementation  Rules 

l)A  <table  name>  must  match  exactly  the  name  of  a  table  in  the  database. 

General  Rules 

1)  A  ctable  definition*  defines  either  a  base  table  or  a  viewed  table.  Which  is  defined  depends  on  the 
definition  of  the  table  within  the  database. 
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6.3.  ccolumn  definition 

Function 

Define  a  column  of  a  table. 

Format 

ccolumn  definition  ::= 

<column  name>  :  <subtype  indication* 

Syntax  Rules 

1)  The  <column  name>  shall  be  different  from  the  <column  name>  of  any  other  <column  definition>  in  the 
containing  ctable  definition>. 

2)  The  n*  column  of  the  table  is  described  by  the  0th  ccolumn  definition>  in  the  ctable  definition>. 

3)  The  description  of  the  column  defined  by  a  ccolumn  definition*  includes  the  name  ccolumn  name>  and 
the  data  type  specified  by  the  ctype  mark>  and  optional  cconstraint>  of  the  csubtype  indication*. 

Level  l  Implementation  Rules 

1)  The  <column  name>  shall  match  the  name  of  the  corresponding  column  in  the  database  table  whose 
name  is  given  by  the  <table  name>  of  the  enclosing  <table  definition>. 

2)  Case: 

a)  If  the  < type  identifier  of  the  <type  mark>  of  the  <subtype  indication>  contains  neither  the 

NOTNULL  nor  the  NO  TNULLJJNIQ UE  suffix,  then  the  corresponding  database  column 
shall  not  have  a  NOT  NULL  or  a  NOT  NULL  UNIQUE  constraint  placed  on  it. 

b ) //  the  <type  identifier  of  the  <type  mark>  of  the  <subtype  indication>  contains  the 

NOT  NULL  suffix,  then  the  corresponding  database  column  shall  be  constrained  to  contain 
only  NOT  NULL  values. 

c)  If  the  <type  identifier  of  the  <type  mark>  contains  the  _NOT_NULL_UNIQUE  suffix,  then  the 
corresponding  database  column  shall  be  constrained  to  contain  only  NOT  NULL  UNIQUE 
values. 


General  Rules 

1)  If  a  column  is  constrained  to  contain  only  nonnull  or  unique  values,  then  the  constraint  is  effectively 
checked  after  the  execution  of  each  cAda/SQL  statement*. 
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6.4.  <unique  constraint  definition 


6.5.  <view  definition> 


6.6.  <privilege  definition> 

These  items  are  not  defined  in  Level  1  Ada/SQL.  They  must  be  defined  for  the  database  using  DBMS  facilities  before 
Ada! SQL  programs  are  run  against  the  database. 
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7.  Program  Environment 


7.1.  <program  environment 

Function 

Define  the  program  environment  of  an  Ada/SQL  program. 

Format 

<program  environment  ::= 

<Ada/SQL  package  compilation  unit ... 

<authorization  package  compilation  unit ... 

<schema  package  compilation  unit ... 

<Ada/SQL  variable  package  compilation  unit ... 

<Ada/SQL  package  compilation  unit  ::= 

<Ada/SQL  context  clause> 

[  <Ada  context  clause>  ] 
clibrary  unit  body> 

<Ada/SQL  context  clause>  ::= 

<with  clause> 

[  <use  clause>  ] 

Syntax  Rules 

1)  The  <with  clause>  and  optional  <use  clause>  of  the  <Ada/SQL  context  clause>  shall  name  all  <schema 
package  compilation  units  and  <Ada/SQL  variable  package  compilation  units  necessary  for  the 
<Ada/SQL  compilation  unit>. 

2)  The  <library  unit  body>  shall  consist  of  regular  Ada  statements  and  <Ada/SQL  DML  statements;*. 

General  Rules 
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7.2.  <Ada/SQL  variable  package  compilation  unit> 


Function 

Define  the  program  variables  that  will  be  used  in  Ada/SQL  DML  statements. 

Format 

<Ada/SQL  variable  package  compilation  unit>  ::= 

<context  clause> 

<Ada/SQL  variable  package  specification> ; 

<Ada/SQL  variable  package  specification*  ::= 
package  <identifier>  is 
[  <use  clause> ...  ] 

[  <variable  declarations>  ...  ] 
end  [  <package  simple  name>  ] 

Syntax  Rules 

1)  The  only  omit  simple  name>s  that  may  be  used  within  a  ccontext  clause>  of  a  <Ada/SQL  variable 
package  compilation  unit>  are  those  of  schema  packages,  plus  the  predefined  package 
CURSOR_DEFINmON. 

2)  The  <v  an  able  declarations>  shall  declare  program  variables  to  be  used  with  the  Ada/SQL  DML 
statements.  All  <variable  declarations>  must  be  of  types  defined  in  <schema  package  compilation 
units>  or  of  type  CURSOR_NAME  defined  in  package  CURSOR_DEFINITION. 

3)  The  <package  simple  name>,  if  used  within  the  <Ada/SQL  variable  package  specification^  must  repeat 
the  <identifier>. 

Level  l  Implementation  Rules. 

1)  Each  <AdalSQL  variable  package  compilation  unit>  shall  be  placed  in  its  own  source  file.  The  name  of 
this  source  file  shall  be  the  same  as  that  of  the  variable  package  defined,  except  that  a  system-dependent 
name  augmentation  may  be  used  to  indicate  that  the  file  contains  Ada  source  code.  This  augmentation 
will  be  defined  for  each  specific  Ada/SQL  system. 

General  Rules 

None. 
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8.  Data  Manipulation  Language 

8.1.  <close  statement 

Function 
Qose  a  cursor. 

Format 

cclose  statement>  ::= 

CLOSE  (  <cursor  name> ) ; 

Syntax  Rules 

1)  The  <cursor  name>  is  a  program  variable  of  type  CURSOR_NAME,  which  is  a  private  type  defined  by 
the  implementation. 

General  Rules 

1)  The  cursor,  CR,  named  by  <cursor  name>,  shall  be  in  the  open  state. 

2)  Cursor  CR  is  placed  in  die  closed  state  and  the  copy  of  the  ccursor  specification>  of  CR  is  destroyed. 
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$.2.  ccommit  statement 

Function 

Terminate  the  current  transaction  with  commit 

Format 

ccommit  statement  ::= 

COMMIT_WORK ; 

Syntax  Rules 

None. 

Level  l  Implementation  Rules 

1)  <commit  statements  shall  not  be  used  with  UNIFY  -  transactions  are  not  supported. 

General  Rules 

1)  The  current  transaction  is  terminated. 

2)  Any  cursors  that  were  opened  by  the  current  transaction  are  closed. 

3)  Any  changes  to  the  database  that  were  made  by  the  current  transaction  are  committed. 
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8.3.  <declare  cursor> 


Function 
Define  a  cursor. 

Format 

<declare  cursor* :  := 

DECLAR  (  <cursor  name> ,  CURSOR_FOR  =>  < cursor  specifications* ) ; 

<cursor  specification  ::= 

cquery  expression*  [ ,  <order  by  clause>  ] 

<query  expression*  ::= 

<query  term> 

I  <query  expression*  &  {  UNION  I  UNION_ALL  }  (  <queiy  term*  ) 

I  <query  expression*  &  {  UNION  I  UNION_ALL  j  <query  term* 

<query  term*  ::= 

<query  specification* 

I  (  <query  expression* ) 

coider  by  clause*  ::= 

ORDER_BY  =>  <sort  specification*  [  {  &  <sort  specification*  }  ...  ] 

<sort  specification*  ::= 

<sort  column  specification* 

I  ACS  ( <sort  column  specification*  ) 

I DESC  ( <sort  column  specification*  ) 

<sort  column  specification*  ::= 
ccolumn  number* 

I  ccolumn  specification* 

Syntax  Rules 

1)  The  ccursor  name*  is  the  cursor  to  be  declared,  a  program  variable  of  type  CURSOR_NAME,  which  is 
a  private  type  defined  by  the  implementation 

2)  If  a  cquery  expression*  including  a  UNION  or  UNION_ALL  contains  an  unparenthesized  cquery 
term*,  then  that  <query  term*  shall  be  of  the  form  (  cquery  expression*  ). 

3)  A  ccolumn  number*  shall  be  a  positive  integer  of  type  COLUMN_NUMBER. 

4)  Let  T  denote  the  table  specified  by  the  ccursor  specification*. 

5)  Case: 

a)  If  ORDER_B  Y  is  specified,  then  T  is  a  read-only  table  with  the  specified  sort  order. 

b)  If  neither  ORDER_BY,  UNION,  nor  UNION_ALL  is  specified  and  the  cquery  specification*  is 
updatable,  then  T  is  an  updatable  table. 

c)  Otherwise,  T  is  a  read-only  table. 

6)  Case: 

a)  If  neither  UNION  nor  UNION_ALL  is  specified,  then  the  description  of  T  is  the  description  of 
the  cquery  specification*. 

b)  If  UNION  or  UNION_ALL  is  specified,  then  for  each  UNION  or  UNION_ALL  that  is  specified, 
except  for  ccolumn  name*s  the  description  of  the  table  specified  by  the  first  cquery  expression* 
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and  the  <query  term>  shall  be  identical.  All  columns  of  the  result  are  unnamed.  Except  for 
<column  name>s  the  description  of  the  result  is  the  same  as  the  description  of  the  tables 
specified  by  the  first  <query  expression>  and  the  <query  term>. 

7)  If  ORDER_BY  is  specified,  then  each  ccolumn  specification>  in  the  <order  by  clause>  shall  identify  a 
column  of  T,  and  each  ccolumn  number*  in  the  corder  by  clause>  shall  be  greater  than  zero  and  not 
greater  than  the  degree  of  T.  A  named  column  may  be  referenced  by  a  ccolumn  number*  or  a  ccolumn 
specifications  An  unnamed  column  shall  be  referenced  by  a  ccolumn  number*. 

Level  l  Implementation  Rules 

1)  No  UNIONS  shall  be  used  with  UNIFY. 

2)  No  <column  numbers>  shall  be  used  as  <sort  column  specification>s  with  UNIFY. 

3)  No  <order  by  clause>  shall  include  GROUP  BY  in  UNIFY. 

General  Rules 

1)  The  ccursor  name>  shall  not  name  an  open  cursor. 

2)  Case: 

a)  If  T  is  an  updatable  table,  then  the  cursor  is  associated  with  the  named  table  identified  by  the 
ctable  name>  in  the  cfrom  clauses  Let  B  denote  that  named  table.  For  each  row  in  T,  there  is  a 
corresponding  row  in  B  from  which  the  row  of  T  is  derived.  When  the  cursor  is  positioned  on  a 
row  of  T,  the  cursor  is  also  positioned  on  the  corresponding  row  of  B. 

b)  Otherwise,  the  cursor  is  not  associated  with  a  named  table. 

3)  Whether  T  is  a  temporary  viewed  table  or  a  temporary  base  table  is  is  defined  by  the  underlying  DBMS. 
Any  program  relying  on  this  is  erroneous. 

4)  Case: 

a)  If  T  is  a  temporary  viewed  table,  then  a  row  of  T  is  derived  only  when  the  cursor  is  positioned  on 
that  row  by  a  cfetch  statement;*. 

b)  If  T  is  a  temporary  base  table,  then  T  is  a  temporary  table  that  is  created  when  the  cursor  is 
opened.  A  temporary  table  persists  until  the  cursor  is  closed. 

5)  Case: 

a)  If  neither  UNION  nor  UNION_ALL  is  specified,  then  T  is  the  result  of  the  specified  cquery 
specifications 

b)  If  UNION  or  UNION_ALL  is  specified,  then  for  each  UNION  or  UNION_ALl,  that  is  specified 
let  T1  and  T2  be  the  result  of  the  <query  expressions  and  the  <query  terms  The  result  of  the 
UNION  or  UNION_ALL  is  derived  as  follows: 

i)  Initialize  the  result  to  an  empty  table. 

ii)  Insert  each  row  of  T1  and  each  row  of  T2  into  the  result. 

iii)  If  UNION_ALL  is  not  specified,  then  eliminate  any  redundant  duplicate  rows  from  the 
result 

6)  Case: 

a)  If  ORDERJ3Y  is  not  specified,  then  the  ordering  of  rows  in  T  is  defined  by  the  underlying 
DBMS.  This  order  is  subject  to  the  reproducibility  requirement  within  a  transaction,  but  it  may 
change  between  transactions.  Any  program  relying  on  this  order  is  erroneous. 

b)  If  ORDER.B  Y  is  specified,  then  T  has  a  sort  order: 

i)  The  sort  order  is  a  sequence  of  sort  groups.  A  sort  group  is  a  sequence  of  rows  in  which 
all  values  of  a  sort  column  are  identical.  Furthermore,  a  sort  group  may  be  a  sequence  of 
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sort  groups. 

ii)  The  cardinality  of  the  sequence  and  the  ordinal  position  of  each  sort  group  is  determined 
by  the  values  of  the  most  significant  sort  column.  The  cardinality  of  the  sequence  is  the 
minimum  number  of  sort  groups  such  that,  for  each  sort  group  of  more  than  one  row,  all 
values  of  that  sort  column  are  identical. 

iii)  If  the  sort  order  is  based  on  additional  sort  columns,  then  each  sort  group  of  more  than 
one  row  is  a  sequence  of  sort  groups.  The  cardinality  of  each  sequence  and  the  ordinal 
position  of  each  sort  group  within  each  sequence  is  determined  by  the  values  of  the  next 
most  significant  sort  column.  The  cardinality  of  each  sequence  is  the  minimum  number 
of  sort  groups  such  that,  for  each  sort  group  of  more  than  one  row,  all  values  of  that  sort 
column  are  identical. 

iv)  The  preceding  paragraph  applies  in  turn  to  each  additional  sort  column.  If  a  sort  group 
consists  of  multiple  rows  and  is  not  a  sequence  of  sort  groups,  then  the  order  of  the  rows 
within  that  sort  group  is  assigned  by  the  underlying  DBMS.  Any  program  relying  on  this 
order  is  erroneous. 

v)  Let  C  be  a  sort  column  and  let  S  denote  a  sequence  which  is  determined  by  the  values  of 
C. 

vi)  A  sort  direction  is  associated  with  each  son  column.  If  the  direction  of  C  is  ascending, 
then  the  first  son  group  of  S  contains  the  lowest  value  of  C  and  each  successive  son 
group  contains  a  value  of  C  that  is  greater  than  the  value  of  C  in  its  predecessor  son 
group.  If  the  direction  is  descending,  then  the  first  son  group  of  S  contains  the  highest 
value  of  C  and  each  successive  sort  group  contains  a  value  of  C  that  is  less  than  the  value 
of  C  in  its  predecessor  sort  group. 

vii)  Ordering  is  determined  by  the  comparison  rules  specified  in  5.11  "<comparison 
predicated'.  The  order  of  the  null  value  relative  to  nonnull  values  is  defined  in  the 
underlying  DBMS,  but  shall  be  either  greater  than  or  less  than  all  nonnull  values.  Any 
program  relying  on  this  order  is  erroneous. 

viii)  A  <sort  specification*  specifies  a  sort  column  and  a  direction.  The  son  column  is  the 
column  referenced  by  the  ccolumn  number*  or  the  ccolumn  specification*.  The 
ccolumn  number*  n  references  the  n*  column  of  R.  A  ccolumn  specification*  references 
the  named  column. 

ix)  If  DESC  is  specified  in  a  csort  specification*,  then  the  direction  of  the  sort  column 
specified  by  that  csort  specification*  is  descending.  If  ASC  is  specified  or  if  neither 
ASC  or  DESC  is  specified,  then  the  direction  of  the  sort  column  is  ascending. 

x) The  csort  specification*  sequence  determines  the  relative  significance  of  the  sort 
columns.  The  sort  column  specified  by  the  first  csort  specification*  is  the  most 
significant  sort  column  and  each  successively  specified  sort  column  is  less  significant 
than  the  previously  specified  sort  column 
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8.4.  <delete  statement:  positioned 

Function 

Delete  a  row  of  a  table  based  on  the  current  position  of  a  cursor. 

Format 

<delete  statement:  positiooed>  ::= 

DF.1  ,ETE_FROM  (  <table  name>  ,  WHERE_CURRENT_OF  =>  <cursor  name>  ) ; 

Syntax  Rules 

1) The  applicable  <privilege>s  for  each  <table  name>  contained  in  the  <table  expression>  shall  include 
DELETE.  Note:  the  " applicable  <privileges> "  for  a  <table  name>  will  be  defined  in  "<privilege 
definition^'  for  later  levels  of  Ada/ SQL.  In  Level  1 ,  privileges  are  as  defined  to  the  underlying  DBMS. 

2)  The  table  designated  by  the  named  cursor,  CR,  shall  not  be  a  read-only  table. 

3)  Let  T  denote  the  table  identified  by  the  <table  name>.  T  shall  be  the  table  identified  in  the  first  <irom 
clause>  in  the  <cursor  specification>  of  CR. 

General  Rules 

1) The  containing  program  environment  shall  contain  a  <declare  cursor*  CR  whose  <cursor  name>  is  the 
same  as  the  <cursor  name>  in  the  <delete  statement:  positioned>. 

2)  Cursor  CR  shall  be  open  and  positioned  on  a  row. 

3)  The  row  from  which  the  current  row  of  CR  is  derived  is  deleted. 


84 


DRAFT 


8.5.  <delete  statement:  searched> 


Function 

Delete  rows  of  a  table  based  on  a  search  criterion. 

Format 

<delete  statement:  seaiched>  ::= 

DELETE_FROM  ( <table  name>  [ ,  WHERE  =>  <search  condi tion>  ] ) ; 

Syntax  Rules 

1)  The  applicable  <pri vile ge>s  for  each  <table  name>  contained  in  the  <table  expression>  shall  include 
DELETE.  Note:  the  "applicable  <privileges> "  for  a  <table  name>  will  be  defined  in  "<privilege 
definition^'  for  later  levels  ofAda/SQL.  In  Level  1 ,  privileges  are  as  defined  to  the  underlying  DBMS. 

2)  Let  T  denote  the  table  identified  by  the  <table  name>.  T  shall  not  be  a  read-only  table  or  a  table  that  is 
identified  in  a  <from  clause>  of  any  <subquery>  contained  in  the  <search  conditions 

3)  The  scope  of  the  <table  name>  is  the  entire  <delete  statement:  searcheds 

General  Rules 

l)Case: 

a)  If  a  <seaich  condition>  is  not  specified,  then  all  rows  of  T  are  deleted. 

b)  If  a  <search  condition>  is  specified,  then  it  is  applied  to  each  row  of  T  with  the  <table  name> 
bound  to  that  row,  and  all  rows  for  which  the  result  of  the  <search  condition>  is  true  are  deleted. 
Each  <subquery>  in  the  <search  condition>  is  effectively  executed  for  each  row  of  T  and  the 
results  used  in  the  application  of  the  <search  coodition>  to  the  given  row  of  T.  If  any  executed 
<subquety>  contains  an  outer  reference  to  a  column  of  T,  the  reference  is  to  the  value  of  that 
column  in  the  given  row  of  T.  Note:  "outer  reference"  is  defined  in  5.7  "ccolumn 
specification^'. 
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8.6.  <fetch  statement 

Function 

Position  a  cursor  on  the  next  row  of  a  table  and  assign  values  in  that  row  to  program  variables. 

Format 

<fetch  statement  ::= 

FETCH  (  <cursor  name> ); 

INTO  (  <rcsult  specification>  [ ,  <cursor  name>  ] ) ; 

[  { INTO  (  <result  specification>  [ ,  <cursor  name>  ]);(...] 

<result  specification*  ::= 
cresult  program  variable> 

[ ,  <last  variable>  ]  [ ,  cindicator  variable>  ] 

Syntax  Rules 

1)  Let  CR  be  the  <declare  cursor*  whose  <cursor  name>  is  the  same  as  the  <cursor  name>  of  the  < fetch 
statements  Let  T  be  the  table  defined  by  the  <cursor  specification*  of  CR. 

2)  A  FETCH  procedure  call  shall  be  followed  by  as  many  calls  to  INTO  as  are  required  to  retrieve  the 
values  of  each  column  in  the  row.  Each  INTO  returns  one  column  value. 

3)  The  <iesult  program  variable>  of  the  i*  INTO  statement  shall  be  a  program  variable  to  obtain  column 
values  from  the  i*  column  of  T.  The  i,h  cresult  program  variables  shall  be  of  the  same  type  as  that  of 
the  i*  column  of  T  being  retrieved. 

4)  The  clast  variable>  shall  be  a  program  variable  to  obtain  the  value  of  the  last  index  position  used  in 
retrieving  array  values  (strings).  It  is  used  when  and  only  when  cresult  program  variable>  is  of  type 
array.  For  one  dimensional  arrays,  which  all  strings  are,  clast  variable>  is  of  the  same  type  as  the  array 
index. 

5)  The  cindicator  variable>  shall  be  an  optional  program  variable  of  type  INDICATORJVARIABLE,  set 
to  NULL_VALUE  if  the  database  column  retrieved  contains  a  null_value,  else  set  to  NOT_NULL.  If  a 
null  value  is  retrieved  from  the  database  but  no  cindicator  variable>  is  specified,  the  NULL_ERROR 
exception  will  be  raised. 

6)  Case: 

a)  If  several  tasks  within  the  same  program  are  simultaneously  performing  database  retrievals,  the 
ccursor  name>  used  in  the  FETCH  must  be  specified  as  the  final  parameter  to  INTO  procedures 
for  that  FETCH. 

b)  If  simultaneous  database  retrievals  are  not  being  performed,  the  ccursor  name>  parameter  may 
be  omitted  from  the  INTO  calls. 


General  Rules 

1)  The  containing  program  environment  shall  contain  a  cdeclare  cursor*  CR  whose  ccursor  name>  is  the 
same  as  the  ccursor  name>  of  the  cfetch  statement*.  This  cursor  shall  be  in  the  open  state. 

2)  If  the  table  designated  by  cursor  CR  is  empty  or  if  the  position  of  CR  is  on  or  after  the  last  row,  CR  is 
positioned  after  the  last  row,  the  exception  NOT_FOUND_ERROR  will  be  raised  and  values  are  not 
assigned  to  the  program  variables  identified  by  the  cresult  specification*. 

3)  The  NOT_FOUND_ERROR  exception  will  be  raised  if  a  FETCH  is  performed  on  a  cursor  for  which  all 
rows  (if  any)  have  already  been  returned 

4)  If  the  position  of  CR  is  before  a  row,  CR  is  positioned  on  that  row  and  values  in  that  row  are  assigned  to 
their  corresponding  program  variables. 

5)  If  the  position  of  CR  is  on  r,  where  r  is  a  row  other  than  the  last  row,  CR  is  positioned  on  the  row 
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immediately  after  r  and  values  in  the  row  immediately  after  r  are  assigned  to  their  corresponding 
program  variables. 

6)  The  order  of  the  assignment  of  values  to  program  variables  is  the  same  as  the  ordering  of  the  INTO 
calls. 

7)  If  an  error  occurs  during  the  assignment  of  a  value  to  a  program  variable,  the  values  returned  by  the 
INTO  statements  are  undefined.  Any  program  relying  on  these  values  is  erroneous. 

8)  The  exception  CONSTRAINT_ERROR  will  be  raised  if  the  result  will  not  fit  in  the  subtype  of  the 
■ore suit  program  variables 

9)  If  the  result  is  a  string  whose  length  is  less  than  the  length  of  the  string  of  the  <result  program  variables 
•clast  variabie>  will  be  set  accordingly  and  the  index  positions  of  <result  program  variable>  beyond 
<last  variable>  will  not  be  altered. 
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8.7.  cinsert  statement 

Function 

Create  new  rows  in  a  table. 

Format 

■cinsert  statement>  ::= 

INSERT_INTO  ( ctable  name>  [  (  cinsert  column  list>  )  ] , 

{  VALUES  <=  cinsert  value  iist>  }  I  cquery  specification>  ) ; 

cinsert  column  list>  ::= 

ccolumn  name>  [  1  &  ccolumn  name>  }  ...  ] 

cinsert  value  list>  ::= 

cinsert  value>  [  {  AND  cinsert  value>  }  ...  ] 

cinsert  value>  ::= 
cvalue  specification* 

I  NULL_VALUE 

Syntax  Rules 

1) The  applicable  cprivilege>s  for  each  ctable  name>  contained  in  the  ctable  expression*  shall  include 
INSERT.  Note:  the  "applicable  <privileges>”  for  a  <table  name>  will  be  defined  in  "<privilege 
definition^'  for  later  levels  of  Ada!  SQL.  In  Level  1 ,  privileges  are  as  defined  to  the  underlying  DBMS. 

2)  Let  T  denote  the  table  identified  by  the  ctable  name>.  T  shall  not  be  a  read-only  table  or  a  table  that  is 
identified  in  a  cfrom  clause>  of  the  cquery  specification>  or  of  any  csubquery>  contained  in  the  cquery 
specification*. 

3)  If  an  cinsert  column  list>  is  used  and  the  ctable  name>  includes  an  cauthorization  identifiers,  then  the 
syntax  for  the  ctable  name>  is  cauthorization  identifier>-ctable  identifiers  This  is  one  of  the  three 
contexts  within  Ada/SQL  where  ctable  name>  syntax  is  not  the  usual  cauthorization  identifier>.ctable 
names 

4)  Each  ccolumn  name>  in  the  cinsert  column  list>  shall  identify  a  column  of  T  and  the  same  column  shall 
not  be  identified  more  than  once.  Omission  of  the  cinsert  column  list>  is  an  implicit  specification  of  a 
cinsert  column  list>  that  identifies  all  columns  of  T  in  the  ascending  sequence  of  their  ordinal  position 
within  T. 

5)  A  column  identified  by  the  cinsert  column  list>  is  an  object  column. 

6)  Case: 

a)  If  an  cinsert  value  list>  is  specified,  then  the  number  of  cinsert  value>s  in  that  cinsert  value  lists 
shall  be  equal  to  the  number  of  ccolumn  namess  in  the  cinsert  column  lists.  Let  the  ith  item  of 
the  cinsert  statements  refer  to  the  i*  cvalue  specifications  in  that  cinsert  value  lists. 

b)  If  a  <query  specifications  is  specified,  then  the  degree  of  the  table  specified  by  that  cquery 
specifications  shall  be  equal  to  the  number  of  ccolumn  namess  in  the  cinsert  column  lists.  Let 
the  i*  item  of  the  cinsert  statements  refer  to  the  i*  column  of  the  table  specified  by  the  cquery 
specifications. 

7)  If  the  i*  item  of  the  cinsert  statements  is  not  the  cinsert  values  NULL_ VALUE,  then,  the  data  type  of 
the  column  of  table  T  designated  by  the  i,h  ccolumn  names  shall  be  the  same  as  the  data  type  of  the  i* 
item  of  the  cinsert  statements. 

Level  l  Implementation  Rules 

1)  NULL  VALUE  may  not  be  used  with  UNIFY. 

2)  With  UNIFY,  a  column  which  would  otherwise  be  set  to  a  null  value  is  instead  set  to  a  default  initial 
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value,  based  on  its  type. 

3)  Constraint  checking  will  not  be  performed  by  Level  1 . 

I  General  Rules 

1)  A  row  is  inserted  in  the  following  steps: 

a)  A  candidate  row  is  effectively  created  in  which  the  value  of  each  column  is  the  null  value.  If  T 
is  a  base  table,  B,  then  the  candidate  row  includes  a  null  value  for  every  column  of  B.  If  T  is  a 
viewed  table,  the  candidate  row  includes  a  null  value  for  every  column  of  the  base  table,  B  from 
which  T  is  derived. 

b)  For  each  object  column  in  the  candidate  row,  the  value  is  replaced  by  an  insert  value. 

c)  The  candidate  row  is  inserted  in  B. 

2)  If  T  is  a  viewed  table  defined  by  a  <view  definition>  that  specifies  "WITH  CHECK  OPTION",  then  if 
the  <query  specification>  contained  in  the  <view  definition>  specified  a  <where  clause>  that  is  not 

I  contained  in  a  <subquery>,  then  the  <search  condition>  of  that  <where  clause>  shall  be  true  for  the 

|  candidate  row. 

I  3)  If  an  <insert  value  list>  is  specified,  then  case: 

a)  If  the  i*  <insert  value>  of  the  <insert  value  list>  is  a  <value  specification^  then  the  ith  value  of 
the  candidate  row  is  the  value  of  that  <value  specifications 

II  b)  If  the  i,h  <insert  value>  of  the  <insert  value  list>  is  NULL_VALUE,  then  the  ith  value  of  the 

candidate  row  is  the  null  value. 

4)  If  a  <query  specification  is  specified,  then  let  R  be  the  result  of  the  cquery  specifications  If  R  is 
empty,  then  the  exception  NOT_FOUND_ERROR  is  raised  and  no  row  is  inserted.  The  number  of 
candidate  rows  created  is  equal  to  the  cardinality  of  R.  The  insert  values  of  one  candidate  row  are  the 
values  in  one  row  of  R  and  the  values  in  one  row  of  R  are  the  insert  values  of  one  candidate  row. 

5)  Let  V  denote  a  row  of  R  or  the  sequence  of  values  specified  by  the  cvalue  lists.  The  nth  value  of  V  is 
the  insert  value  of  the  object  column  identified  by  the  nth  ccolumn  name>  in  the  <insert  column  lists. 

6)  If  an  cinsert  value>  is  a  string  which  is  longer  than  the  ccolumn  name>  can  hold,  then  cinsert  value> 
will  be  truncated. 

7)  If  an  cinsert  value>  is  a  string  which  is  shorter  than  the  ccolumn  name>  can  hold,  then  cinsert  value> 

“  will  be  padded  with  spaces. 
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8.8.  copen  statement 


Function 
Open  a  cursor. 

Format 

copen  statement*  ::= 

OPEN  ( ccursor  name> ) ; 

Syntax  Rules 

None. 

General  Rules 

1)  A  previously  executed  cdeclare  cuisor>  shall  have  associated  a  ccursor  specification>  with  ccursor 
name>  CR. 

2)  Cursor  CR  shall  be  in  the  closed  state. 

3)  Let  S  denote  the  ccursor  specification>  of  cursor  CR. 

4)  Cursor  CR  is  opened  in  the  following  steps: 

a)  If  S  specifies  a  read_only  table,  then  that  table,  as  specified  by  the  copy  of  S.  is  effectively 
created. 

b)  Cursor  CR  is  placed  in  the  open  state  and  its  position  is  before  the  first  row  of  the  table. 
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8.9.  <rollback  statement 

Function 

Terminate  the  current  transaction  with  rollback. 

Format 

<rollback  statement  ::= 

ROLLBACK.WORK ; 

Syntax  Rules 

None. 

Level  /  Implementation  Rules 

1)  <rollback  statement >s  shall  not  be  used  with  UNIFY. 

General  Rules 

1)  Any  changes  to  the  database  that  were  made  by  the  current  transaction  are  canceled. 

2)  Any  cursors  that  were  opened  by  the  current  transaction  are  closed. 

3)  The  current  transaction  is  terminated. 
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8.10.  <select  statement 
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Function 

Specify  a  table  and  assign  the  values  in  the  single  row  of  that  table  to  program  variables. 

Format 

<select  statement*  ::= 

[  SELEC I  SELECT_ALL  I  SELECT.DISTINCT  ]  (  cselect  list>  , 

<table  expression ) ; 

INTO  ( <result  specification>  ) ; 

[  {  INTO  ( <result  specification^ );}...] 

Syntax  Rules 

1) The  applicable  <privilege>s  for  each  <table  name>  contained  in  the  <table  expression*  shall  include 
SELEC.  Note:  the  "applicable  <privileges>“  for  a  <table  name>  will  be  defined  in  "<privilege 
definition^' for  later  levels  of  Ada!  SQL.  In  Level  l,  privileges  are  as  defined  to  the  underlying  DBMS. 

2)  The  <table  expression*  shall  not  include  a  <group  by  clause>  or  a  <having  clause>  and  shall  not 
identify  a  grouped  view. 

3)  The  number  of  elements  in  the  <select  list>  shall  be  the  same  as  the  number  of  following  INTO  calls. 

4)  The  data  type  of  the  <iesult  program  variable>  of  the  <result  specification*  in  the  1th  INTO  call  shall  be 
the  same  as  the  data  type  of  the  i*  cvalue  expression*  in  the  <select  list>. 

5)  The  <last  variable>  within  cresult  specification*  shall  be  a  program  variable  to  obtain  the  value  of  the 
last  index  position  used  in  retrieving  array  values  (strings).  It  is  used  when  and  only  when  <result 
program  variable>  within  <result  specification*  is  of  type  array.  For  one  dimensional  arrays,  which  all 
strings  are,  <last  variable>  within  <result  specification*  is  of  the  same  type  as  the  array  index. 

6)  The  <indicator  variable>  within  the  cresult  specification*  shall  be  an  optional  program  variable  of  type 
INDIC ATOR_V ARIABLE,  set  to  NULL_ VALUE  if  the  database  column  retrieved  contains  a 
null.value,  else  set  to  NOT_NULL.  If  a  null  value  is  retrieved  from  the  database  but  no  cindicator 
variable>  within  cresult  specification*  is  specified,  the  NULL_ERROR  exception  will  be  raised. 

General  Rules 

1)  A  ccursor  name>  is  not  defined  in  the  cselect  statement:*.  Consequently,  tasks  within  a  program  must 
not  perform  more  than  one  simultaneous  cselect  statements  If  multiple  retrievals  must  be  performed 
simultaneously,  FETCH  statements  must  be  used  to  avoid  erroneous  results. 

2)  Let  S  be  a  cquery  specification*  whose  cselect  lists  and  ctable  expression*  are  those  specified  in  the 
cselect  statement  and  which  specifies  SELECT_ALL  or  SELECT_DISTINCT  if  it  is  specified  in  the 
cselect  statement*.  Let  R  denote  the  result  of  cquery  specification*  S. 

3)  The  cardinality  of  R  shall  not  be  greater  than  one.  The  UNIQUE_ERROR  exception  will  be  raised  if  the 
cselect  statement*  retrieved  more  than  one  row,  resulting  in  the  cardinality  of  R  being  greater  than  one. 
If  R  is  empty,  then  the  NOT_FOUND_ERROR  exception  will  be  raised. 

4)  If  R  is  not  empty,  then  values  in  the  row  of  R  are  assigned  to  their  corresponding  program  variables. 

3)  The  order  of  the  assignment  of  values  to  program  variables  is  the  same  as  the  ordering  of  the  INTO 
calls. 

6)  If  an  error  occurs  during  the  assignment  of  a  value  to  a  program  variable,  the  values  returned  by  the 
INTO  statements  are  undefined.  Any  program  relying  on  these  values  is  erroneous. 

7)  The  cresult  specificahon>  of  the  n*  INTO  calls,  corresponds  to  the  n*  value  in  the  row  of  R. 

8)  The  exception  CONSTRAINT_ERROR  will  be  raised  if  the  result  will  not  fit  in  the  subtype  of  the 
cresult  program  variable:*. 
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9)  If  the  result  is  a  string  whose  length  is  less  than  the  length  of  the  string  of  the  <result  program  variables 
<last  variable>  will  be  set  accordingly  and  the  index  positions  of  <result  program  variable>  beyond 
<last  variable>  will  not  be  altered. 
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8.11.  <update  statement:  positioned 


Function 

Modify  a  row  of  a  table  based  on  a  cursor’s  current  position. 

Format 

<update  statement:  positioned>  ::= 

UPDATE  (  <table  name> , 

SET  =>  <set  clause>  [  {  AND  <set  clause> 

WHERE_CURRENT_OF  =>  <cursor  name> ) ; 

<setclause>  ::= 

<object  column>  <=  {  <value  expression  I  NULL_ VALUE  } 

<object  column>  ::= 

<column  name> 

Syntax  Rules 

1) The  applicable  <privilege>s  for  each  <table  name>  contained  in  the  ctable  expression>  shall  include 
UPDATE.  Note:  the  "applicable  <privileges>"  for  a  <table  name>  will  be  defined  in  "<privilege 
definition^  for  later  levels  ofAda/SQL.  In  Level  I, privileges  are  as  defined  to  the  underlying  DBMS. 

2)  The  table  designated  by  CR  shall  not  be  a  read-only  table. 

3)  Let  T  denote  the  table  identified  by  the  <table  name>.  T  shall  be  the  table  identified  in  the  first  cfrotn 
clause>  in  the  < cursor  specification>  of  CR. 

4)  A  <value  expression  in  a  <set  clause>  shall  not  include  a  <set  function  specifications 

5)  The  same  cobject  column>  shall  not  appear  more  than  once  in  an  <update  statement:  positioned^ 

6)  For  each  <set  clause>,  case: 

a)  If  NULL_ VALUE  is  specified,  then  the  column  designated  by  the  cobject  column> 
nulls. 

b)  The  data  type  of  the  column  designated  by  the  cobject  column>  shall  be  the  same 
type  of  the  cvalue  expression>  for  that  column. 

Level  /  Implementation  Rules 

1)  c  update  statement:  positioned>  shall  not  be  used  with  UNIFY. 

2)  Subtype  constraint  checking  will  not  be  performed  by  Level  l . 

General  Rules 

1)  Cursor  CR  shall  be  opened  and  positioned  on  a  row. 

2)  The  object  row  is  that  row  from  which  the  current  row  of  CR  is  derived. 

3)  The  object  row  is  updated  as  specified  by  each  cset  clause>.  A  cset  clause>  specifies  an  object  column 
and  an  update  value  of  that  column.  The  object  column  is  the  column  identified  by  the  cobject  column> 
in  the  cset  clause>.  The  update  value  is  the  null  value  or  the  value  specified  by  the  cvalue  expressions 
If  the  cvalue  expression>  contains  a  reference  to  a  column  of  T,  the  reference  is  to  the  value  of  that 
column  in  the  object  row  before  any  value  of  the  object  row  is  updated. 

4)  The  object  row  is  updated  in  the  following  steps: 

a)  A  candidate  row  is  created  which  is  a  copy  of  the  object  row. 

b)  For  each  cset  clauses  the  value  of  the  specified  object  column  in  the  candidate  row  is  replaced 
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by  the  specified  update  value, 
c)  The  object  row  is  replaced  by  the  candidate  row. 

5)  If  T  is  a  viewed  table  defined  by  a  <view  definition*  that  specifies  "WITH  CHECK  OPTION",  then  if 
the  <queiy  specification*  contained  in  the  <view  definition*  specifies  a  <where  clause*  that  is  not 
contained  in  a  <subquery>,  then  the  <search  condition*  of  that  <where  clause*  shall  be  true  for  the 
candidate  row. 

6)  The  containing  program  environment  shall  contain  a  < declare  cursor*  CR  where  < cursor  name*  is  the 
same  as  the  ccursor  name*  in  the  <update  statement:  positioned*. 

7)  If  a  <set  clause*  is  a  string  which  is  longer  than  the  column  of  the  <table  name*  being  updated,  then  the 
<set  clause*  will  be  truncated. 

8)  If  a  <set  clause*  is  a  string  which  is  shorter  than  the  column  of  the  <table  name*  being  updated,  then  the 
<set  clause*  will  be  padded  with  spaces. 
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8.12.  cupdate  statement:  searched> 


Function 

Modify  rows  of  a  table  based  on  a  search  condition. 

Format 

•cupdate  statement:  searched>  ::= 

UPDATE  (  ctable  name> , 

SET  =>  <set  clause>  [  (  AND  <set  clause>  }...], 

WHERE  =>  csearch  condi tion>  ) ; 

Syntax  Rules 

1)  The  applicable  <privilege>s  for  each  ctable  name>  contained  in  the  ctable  expression>  shall  include 
UPDATE.  Note:  the  " applicable  <privileges> "  for  a  <table  name>  will  be  defined  in  "<privilege 
definition^'  for  later  levels  of  Ada!  SQL.  In  Level  I,  privileges  are  as  defined  to  the  underlying  DBMS. 

2)  Let  T  denote  the  table  identified  by  the  ctable  name>.  T  shall  not  be  a  read-only  table  or  a  table  that  is 
identified  in  a  cfrom  clause>  of  any  csubquery>  that  is  contained  in  the  csearch  conditions 

3)  A  cvalue  expression>  in  a  cset  ciause>  shall  not  include  a  cset  function  specifications 

4)  The  same  cobject  column>  shall  not  appear  more  than  once  in  an  cupdate  statement:  searcheds 

5)  The  scope  of  the  ctable  name>  is  the  entire  cupdate  statement:  searcheds 

6)  For  each  cset  clauses  case: 

a)  If  NULL_ VALUE  is  specified,  then  the  column  designated  by  the  cobject  column>  shall  allow 
nulls. 

b)  The  data  type  of  the  column  designated  by  the  cobject  column>  shall  be  the  same  as  the  data 
type  of  the  cvalue  expression>  for  that  column. 

Level  I  Implementation  Rules 

1)  NULL  ^VALUES  shall  not  be  used  in  a  <set  clause>  with  UNIFY. 

2)  Subtype  constraint  checking  will  not  be  performed  by  Level  1. 

General  Rules 

1)  Case: 

a)  If  a  csearch  condition>  is  not  specified,  then  all  rows  of  T  are  the  object  rows. 

b)  If  a  csearch  condition>  is  specified,  then  it  is  applied  to  each  row  of  T  with  the  ctable  name> 
bound  to  that  row,  and  the  object  rows  are  those  rows  for  which  the  result  of  the  csearch 
condition>  is  true.  Each  csubquery>  in  the  csearch  condition>  is  effectively  executed  for  each 
row  of  T  and  the  results  used  in  the  application  of  the  csearch  condi tion>  to  the  given  row  of 
T.  If  any  executed  csubquery>  contains  an  outer  reference  to  a  column  of  T,  the  reference  is  to 
the  value  of  that  column  in  the  given  row  of  T.  Note:  "outer  reference"  is  defined  in  5.7 
"ccolumn  specification^'. 

2)  Each  object  row  is  updated  as  specified  by  each  cset  clause>.  A  cset  clause>  specifies  an  object  column 
and  a  update  value  of  that  column.  The  object  column  is  the  column  identified  by  the  cobject  co!umn> 
in  the  cset  clause >.  The  update  value  is  the  null  value  or  the  value  specified  by  the  cvalue  expressions 
If  the  cvalue  expression>  contains  a  reference  to  a  column  of  T,  the  reference  is  to  the  value  of  that 
column  in  the  object  row  before  any  value  of  the  object  row  is  updated. 

3)  The  object  row  is  updated  in  the  following  steps: 

a)  A  candidate  row  is  created  which  is  a  copy  of  the  object  row. 
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b)  For  each  <set  clause>,  the  value  of  the  specified  object  column  in  the  candidate  row  is  replaced 
by  the  specified  update  value. 

c)  The  object  row  is  replaced  by  the  candidate  row. 

4)  If  T  is  a  viewed  table  defined  by  a  <view  definition>  that  specifies  "WITH  CHECK  OPTION",  then  if 
the  <query  specification>  contained  in  the  <view  definition>  specifies  a  <where  clause>  that  is  not 
contained  in  a  <subquery>,  then  the  <search  condi tion>  of  that  <where  clause>  shall  be  true  for  the 
candidate  row. 

5)  If  a  <set  clause>  is  a  string  which  is  longer  than  the  column  of  the  <table  name>  being  updated,  then  the 
<set  clause>  will  be  truncated. 

6)  If  a  <set  clause>  is  a  string  which  is  shorter  than  the  column  of  the  <table  name>  being  updated,  then  the 
<set  clause>  will  be  padded  with  spaces. 
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